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This  thesis  addresses  the  problem  of  maintaining  the 
TCP-based  applications  of  a  subscriber  in  a  mobile 
environment.  Two  solutions  to  the  problem  of  addressing 
these  mobile  subscribers  has  been  suggested.  The  first 
scheme  of  addressing  is  to  use  logical  addresses  at  the 
internet  level  and  the  second  is  to  use  separate  addresses 
at  the  transport  level  of  the  protocol  hierarchy.  The 
performance  of  the  two  proposed  solutions  are  analyzed 
through  the  use  of  a  simulation  program  based  on  queueing 


model s . 


A  mobile  subscriber  is  actually  a  host  computer  that 
travels  around  in  a  network  or  from  one  network  to  another. 
The  development  of  packet  radio  technology  has  been 
stimulated  by  the  need  to  provide  computer  network  access 
to  mobile  subscribers.  Packet  radio  offers  a  highly 
efficient  way  of  using  a  multiple  access  channel, 
particularly  with  mobile  subscribers.  Good  connectivity 
can  be  maintained  in  a  packet  radio  network  with  mobile 
subscribers  as  long  as  a  line  of  sight  path  exists,  or  a 
system  of  relays  is  used  to  complete  the  transmission  of 
data,  [  1 ] 

Packet  switching  networks  use  a  hierarchy  of 
protocols  for  the  transfer  of  packets  of  information  among 
network  subscribers.  The  transmission  control  protocol 
(TCP)  and  the  internet  protocol  (IP)  used  in  DoD  data 
networks  at  the  transport  level  are  a  suitable  choice  to  be 
used  in  the.  environment  of  this  study.  TCP/IP  interfaces 
on  the  lower  level  with  the  communications  network  and  on 
the  upper  level  to  the  user  or  application  process.  This 
relationship  can  be  seen  in  figure  1.  TCP/IP  are  expected 
to  operate  within  military  environments  where  deliberate 
physical  destruction  and  electronic  interference  aimed  at 


the  communication  systems  simply  must  not  degrade  essential 
network  services.  Connections  are  opened  from  one 
subscriber  to  another  by  TCP  using  an  internetwork  address 
to  partially  define  the  connection.  This  address  is  shared 
and  also  used  by  IP  for  routing  packets.  [2] 

USER 

TCP/IP 

NETWORK 

LINK 

PHYSICAL 

Figure  1.  Protocol  Hierarchy 

This  thesis  addresses  the  problem  of  maintaining  the 
TCP-based  applications  of  a  subscriber  in  a  mobile 
environment.  That  is,  can  a  subscriber  keep  TCP  (virtual) 
connections  open  while  moving  around  an  internet  system? 

The  specific  question  that  needs  to  be  answered  on  a 
general  level  is:  how  would  a  host  carried  on  a  helicopter 
manage  to  preserve  its  TCP-based  applications  while  it 
flies  out  of  radio  contact  with  one  packet  radio  and  into 
contact  with  another  packet  radio  net? 

jScoP-S 

Possible  solutions  to  be  explored  in  the  problem  of 
addressing  mobile  subscribers  will  be  limited  to  those 
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using  logical  addresses  at  the  internet  level  and  those 
using  separate  addresses  at  the  transport  level  of  the 
protocol  hierarchy. 


Assumptions 

The  problem  will  be  generalized  by  considering  the 
host  computer  being  carried  not  only  on  a  helicopter  and 
the  contraints  it  imposes,  but  that  the  host  may  be  carried 
in  a  fixed-wing  aircraft  or  on-board  a  ship. 

£mnnmiiy  ol  Current  Knowledge 

In  this  section,  a  review  of  the  current  literature 
will  include  the  areas  of  packet  radio  technology,  some  of 
the  problems  encountered  in  having  mobile  subscribers  in 
multi-network  systems,  and  how  Transmission  Control 
Protocol  (TCP)  /  Internet  Protocol  (IP)  function. 

"Packet  radio  is  a  technology  that  extends  the  original 
packet  switching  concepts  which  evolved  for  networks  of 
point-to-point  communication  lines  to  the  domain  of 
broadcast  radio  networks."  [1:1468]  A  packet  radio  network 
is  appropriate  for  use  in  a  hostile  environment  with  mobile 
subscribers  because  of  its  rapid  and  convenient  deployment 
capability,  survivability,  and  ease  of  reconfiguration.  In 
this  application,  packet  radio  is  also  appropriate  because 
of  its  ability  to  support  mobile  users  over  a  large 
geographical  area.  The  area  coverage  is  easily  expandable 
and  the  number  of  users  connected  may  also  change.  Packet 
radio  is  also  capable  of  existing  with  other  packet  radio 


networks,  and  is  therefore  appropriate  for  use  in  a  multi¬ 
network  environment.  [3:99] 

Supporting  real-time  interactions  between  subscribers 
is  the  primary  objective  of  a  packet  radio  network.  In 
order  to  satisfy  this  requirement,  there  are  several  basic 
functions  a  packet  radio  network  must  provide.  These  basic 
functions  can  be  divided  into  two  subgroups:  those  which 
are  automatically  provided  and  those  which  a  subscriber  may 
ask  for  specifically.  The  first  group  includes  functions 
such  as  the  following: 

1.  Network  transparency  -  the  subscriber  should  only 
have  to  give  a  destination  address  and  not  have  to  be 
concerned  with  routing,  reliability,  and  other  networking 
concerns . 

2.  Area  coverage  and  connectivity  -  the  network 
should  allow  area  coverage  to  be  expanded  at  the  expense  of 
end-to-end  delay.  The  network  should  allow  any  subscriber 
to  connect  with  any  other  subscriber. 

3.  Mobility  -  the  system  should  support  mobile 
subscribers. 

4.  Internetting  -  the  network  should  be  capable  of 
routing  packets  for  another  network  to  the  point  of 
connection  with  that  other  network. 

5.  Throughput  and  low  delay  -  the  network  should 
allow  for  variable  length  packets  which  should  be  delivered 
with  very  short  delays  to  maintain  the  real-time 
interactive  ability. 


6.  Rapid  and  convenient  deployment  -  deployment 
should  require  no  more  than  mounting  the  equipment.  The 
network  should  discover  the  connectivity  between 
subscribers.  In  other  words,  the  system  should  be  self- 
initializing. 

The  second  group,  those  which  the  subscriber  must  ask 
for  specifically,  includes  functions  such  as: 

1.  Error  control  -  error  control  should  be  provided 
by  the  network,  although  the  subscriber  should  have  the 
option  of  what  method  should  be  used  for  correction. 

2.  Routing  options  -  the  subscriber  should  be  able 
to  specify  the  type  of  routing  used  through  its  parameters. 
For  example,  the  subscriber  may  choose  either  point-to- 
point  or  broadcast  as  the  type  of  routing  to  be  used. 

3.  Addressing  Options  -  the  network  should  provide  a 
capability  for  addressing  a  subset  of  subscribers. 

4.  Tactical  Applications  -  in  tactical  military 
operations  the  packet  radio  should  provide  resistance  to 
jamming,  detection,  and  direction  finding.  [1] 

The  network  topology  is  a  dynamic  topology  in  an 
environment  where  the  subscribers  are  frequently  or 
constantly  changing  their  locations.  Performance  limits 
are  imposed  on  the  system  by  the  presence  of  mobile 
subscribers.  Where  point-to-point  routing  is  used,  the 
maximum  allowable  speed  for  mobile  subscribers  is  limited 
by  the  time  it  takes  the  system  to  adapt  to  changes  along  a 
subscribers  path. There  are  several  methods  for  routing 


packets  of  data  in  such  a  network  topology.  Two  such 
methods  which  will  be  discussed  here  are  a  broadcast 
routing  algorithm  and  an  algorithm  which  utilizes  a  base 
station.  [4,5] 

In  a  broadcast  network  the  major  decision  is  whether 
to  accept  a  packet  or  to  reject  it,  not  to  determine  which 
outgoing  line  to  use  as  is  done  in  a  point-to-point  network 
(such  as  the  ARPAnet). 

A  broadcast  routing  algorithm  transmits  the  packet  to 
all  subscribers  in  the  network.  Each  subscriber  determines 
whether  that  packet  was  intended  for  it,  whether  to  forward 
the  packet,  or  whether  to  discard  the  packet.  Broadcast 
routing  is  very  practical  in  networks  where  subscribers  are 
mobile  and  locations  are  not  always  known.  No  addressing 
is  used  in  this  scheme,  a  subscriber  recognizes  packets 
sent  to  it  by  comparing  the  destination  ID  against  its  own 
ID.  [6:926-927] 

The  basic  network  model  where  subscribers  cannot  rely 
on  line-of-sight  transmission  from  sender  to  receiver 
utilizes  a  base  station  which  relays  the  packets  from 
sender  to  receiver.  The  sender  transmits  a  packet  to  the 
base  station.  The  base  station  then  signals  to  all 
subscribers  that  a  packet  is  available  to  be  transmitted. 
The  destination  subscriber  recognizes  that  the  packet  is 
addressed  to  it  and  signals  to  the  base  stations  that  it  is 
ready  to  receive  the  packet.  The  base  station  then  relays 
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the  packet  to  its  destination  subscriber,  thus  completing 
the  transmission.  [73 

The  next  topic  of  this  section  deals  with  the 
interconnecting  of  networks.  To  allow  subscribers  in 
different  networks  to  communicate  with  each  other,  a  basic 
set  of  problems  such  as  addressing  and  routing  procedures, 
must  be  solved.  The  problem  of  addressing  in  a  mobile 
environment  are  discussed  in  Chapter  2. 

One  approach  to  addressing  and  routing  in  large 
systems  is  to  use  hierarchical  methods.  A  switch  serves  a 
subset  of  the  subscribers  in  transmitting  packets.  If 
every  switch  maintained  routing  information  for  every 
destination  subscriber,  the  routing  tables  would  become 
very  large.  To  reduce  routing  table  size,  the  method  of 
hierarchical  addressing  is  suggested.  Each  network  has  a 
number  of  switches.  Each  switch  has  a  number  of  ports,  one 
for  each  subscriber  serviced  by  that  switch.  Each  address 
would  then  contain  a  network  address,  a  switch  address,  and 
a  port  address  <net, switch, port>.  Routing  may  be  done  by 
sending  packets  for  any  subscriber  in  a  particular  net  in 
the  switch  over  the  same  route,  thus  reducing  the  number  of 
entries  in  the  routing  table.  The  reduction  of  routing 
tables  has  its  price;  the  resulting  routes  may  not  always 
be  optimal  [5].  Thus  it  can  be  seen  that  some  solutions  to 
some  problems  result  in  other  problems. 

The  ARPA  sponsored  work  on  networks  has  resulted  in 
the  development  of  an  internet  protocol  (IP)  and  a 


transmission  control  protocol  (TCP)  to  handle  the  problems 
encountered  in  the  interconnection  of  networks.  Networks 
are  interconnected  by  gateway  computers  that  appear  to  be 
local  subscribers  on  two  or  more  nets.  The  gateways  are 
responsible  for  routing  traffic  across  multiple  networks, 
and  for  forwarding  messages  across  each  net  using  the 
packet  transmission  protocol  in  each  network.  This 
approach  allows  the  interconnection  of  networks  that  have 
significantly  different  internal  protocols  and  performance. 
Gateways  provide  an  internet  service  by  means  of  IP.  The 
format  of  the  internet  packets  and  the  rules  for  performing 
internet  protocol  functions  based  on  the  control 
information  in  the  packets  is  provided  by  IP.  IP  must  be 
implemented  in  subscribers  engaged  in  internet 
communication  as  well  as  in  the  gateways.  [8]  A  more 
detailed  look  at  IP  and  TCP  follows. 

TCP/IP  developed  as  the  direct  result  of  the 
evolution  of  the  DoD  Internet  Architecture  Model  as 
described  by  Cerf  and  Cain.  [9]  TCP  developed  as  a  highly 
reliable,  logical  connection,  end-to-end  transport  protocol 
which  would  reside  within  each  host.  IP  developed  as  a 
very  simple  datagram  protocol  which  would  reside  in  the 
hosts  as  well  but  would  also  provide  the  internetwork 
protocol  within  the  more  vulnerable  gateways  and  IMP's. 

[ 10:607 ] 

The  TCP  is  a  highly  reliable,  end-to-end,  logical 
connection  transport  level  protocol  which  logically  functions 


§ 

! 

I* 

h* 


within  a  packet  switched  environment  between  hosts  on  a 

single  network  or  between  hosts  in  an  internetwork  system. 

TCP  makes  few  assumptions  concerning  any  of  the  layers 

below  itself  other  than  that  a  simple  datagram  service 

exists  which  is  probably  unreliable.  [2:1]  In  this  case 

the  simple  datagram  service  is  IP.  Consequently,  TCP  must 

perform  in  the  following  areas  [2:33: 

Basic  Data  Transfer 

Reliability 

Flow  Control 

Multiplexing 

Connections 

Precedence 

TCP's  high  reliability  is  due  to  the  assignment  of  a  unique 
sequence  number  to  each  octet  (i.e.,  8  bits)  transmitted 
and  to  the  use  of  a  positive  acknowledgement  scheme  between 
hosts  [2:4].  TCP  controls  the  flow  of  segments  via  a 
window  technique  much  as  that  described  by  Tannenbaum 
[11:148-164]  at  the  data  link  layer.  A  window  is  sent  back 
with  each  ACK  containing  a  maximum  sequence  number  that  a 
host  is  willing  to  accept.  By  subtracting  the  last 
sequence  number  sent  from  the  maximum  sequence  number 
received  in  an  ACK  segment,  a  host  can  determine  the 
number  of  octets  he  is  subsequently  allowed  to  transmit. 

TCP  allows  processes  within  a  host  to  multiplex  on  the 
communications  lines  attached  to  the  hosts  by  providing 
sockets  which  any  process  may  use.  A  socket  is  composed  of 
the  concatenation  of  a  host  communications  port  address  and 
the  internetwork  and  host  address.  A  pair  of  sockets  would 
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then  uniquely  identify  a  connection  between  two  processes. 
Finally,  the  TCP  security  and  Precedence  function  is 
essentially  enacted  through  the  internet  layer  below  it.  A 
more  detailed  description  of  each  of  these  functions  can  be 
found  in  [  2  ] . 

The  Connections  function  of  the  TCP  is  the  management 
of  establishing,  maintaining  and  closing  communications 
between  two  processes  residing  on  two  different  hosts.  A 
connection  is  established  between  two  processes  when  a  pair 
of  sockets  has  been  identified,  initial  sequence  numbers 
have  been  exchanged  and  window  sizes  have  been  established. 

TCP  uses  a  three  way  handshake  to  perform  these  tasks.  [2] 

Once  a  connection  is  established,  the  users  may 
exchange  data.  Since  TCP  uses  a  positive  acknowledgement 
scheme  each  data  segment  must  carry  an  A CK.  Also,  because 
TCP  is  designed  to  be  highly  reliable,  a  checksum  is 
calculated  for  all  octets  within  the  data. 

Retransmissions,  based  on  a  timeout,  are  sent  until  ACK  is 
received  guaranteeing  deliver  of  every  segment.  [2:40] 

This  data  exchange  cycle  continues  until  a  close  request  is 
initiated. 

TCP,  in  order  to  implement  these  functions,  prefixes  the 
data  transmitted  with  a  TCP  header  as  shown  in  Fig.  3.  The 
header  is  a  sequence  of  32-bit  words  with  up  to  a  maximum  of 
6  words  (variable  due  to  the  options)  per  segment.  A 
complete  definition  of  each  of  the  fields  shown  in  Fig.  2  is 
given  in  [ 2 ] . 


0  12  3 
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Figure  2.  TCP  Header  Format 


The  IP  is  a  simple  internetwork,  datagram  protocol 


which  provides  no  end-to-end  services  but  merely  offers  a 
datagram  to  the  communications  network  and  forgets  it.  The 


IP  Standard  succintly  describes  what  the  protocol  is  and  is 


not:  "The  internet  protocol  implements  two  basic 


functions:  addressing  and  fragmentation.  ...The  internet 


protocol  does  not  provide  a  reliable  communiction 


facitlity.  There  are  no  acknowledgments  wither  end-to-end 


or  hop-by-hop.  There  is  no  error  control  for  data  only  a 


header  checksum.  There  are  no  retransmissions.  There  is 


no  flow  control."  [12:2-3] 


The  IP  Standard  makes  a  distinction  between  names, 


addresses  and  routes.  Basically,  the  IP  uses  addresses  to 


define  where  a  named  host  resides  in  the  network.  IP 


Figure  3.  IP  Header  Format 


simply  translates  between  names  and  addresses  to  allow  the 
lower  levels  to  correctly  route  the  datagrams  [12:73.  The 
IP's  fragmentation  function  allows  arbitrarily  long  (max 
64K  octets)  segments  to  traverse  a  number  of  networks  whose 
segment  lengths  may  vary.  Like  TCP  these  functions  depend 
on  a  header  prefixed  to  transmitted  data.  Fig.  3  depicts 
the  IP  header.  The  IP  Standard  contains  full  descriptions 
of  all  these  fields  [12]. 

As  we  have  seen  in  this  brief  survey  of  a  packet 
radio  multi-network  environment  with  mobile  subscribers 
that  packet  radio  is  an  appropriate  choice  in  military 
applications.  We  have  also  seen  that  there  are  many 
problems  involved  in  allowing  subscribers  to  be  mobile. 
Problems  exist  in  addressing  and  routing  within  a 
communication  network  with  or  without  mobile  subscribers. 
From  this  brief  survey  one  can  see  that  much  research 


remains  to  be  done  in  the  areas  of  routing  and  addressing 
to  improve  efficiency  and  to  reduce  costs  in  a  packet  radio 
internetwork  with  mobile  subscribers. 


Appn?ac.Ii 

In  this  thesis,  a  summary  of  current  literature  is 
presented  of  specific  definitions  and  proposed  solutions  to 
the  model  radio  networking  problem.  Next,  the  possible 
solutions  of  using  logical  addresses  at  the  IP  level  or 
using  separate  addresses  at  the  TCP  level  will  be  explored. 
Lastly,  a  cost/benefit  analysis  of  the  above  solutions 
will  be  done.  The  method  used  to  explore  these  solutions 
and  to  conduct  a  cost/benefit  analysis  is  that  of  a 
computer  simulation  of  the  mobile  subscriber  environment 
described  in  the  background  section.  The  results  of  this 
computer  simulation  is  used  to  compare  the  two  proposed 
solutions. 

Th.epls  Q-V.eryl.ew 

Chapter  2  contains  the  results  of  the  literature  search 
performed  to  identify  previous  problem  definition  and  the 
proposed  solutions.  Chapter  3  describes  the  two  techniques 
of  addressing  which  are  evaluated  as  solutions  to  the 
problem  as  stated  above  in  the  problem  section.  Chapter  4 
contains  a  discussion  of  the  computer  simulation.  Included 
in  this  chapter  is  the  development  of  the  models  used  to 
represent  each  proposed  solution.  Chapter  5  contains  the 
results  of  the  computer  simulation  including  the 
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cost/benefit  analysis  of  each  of  the  proposed  solutions. 
Chapter  6  describes  the  results  and  conclusions  of  this 
research  and  possible  extensions  of  this  effort. 


The  results  of  the  literature  search  performed  to 
identify  previous  definitions  of  the  problem  of  addressing 
mobile  subscribers  and  the  proposed  solutions  to  the 
problem  are  presented  in  this  chapter.  Addressing  a 
subscriber  in  a  network  with  only  nonmobile  subscribers 
does  not  include  the  problem  of  maintaining  a  connection  as 
the  physical  address,  or  location,  of  the  subscribers  will 
not  change.  The  problem  of  addressing  mobile  subscribers 
occurs  when  the  subscribers  change  their  physical  address. 
In  this  discussion  the  term  "node"  is  used  to  refer  to  the 
switching  computer  in  the  network,  and  "subscriber"  is  used 
to  refer  to  the  host  computer  or  terminal  equipment 
connected  to  the  network.  Connection  of  the  subscriber  to 
the  node  is  over  a  communications  circuit  terminating  at  a 
port  on  the  node.  A  subscriber  can  be  addressed  by  the 
node  number  and  port  number  to  which  it  is  connected  within 
a  given  network;  this  is  referred  to  as  "physical 
addressing".  [13]  A  brief  discussion  of  what  an  address 
is  and  where  it  fits  into  the  scheme  of  things  is 
presented . 

Names,  addresses,  and  routes  are  three  distinct 
entities  in  an  internet.  The  name  of  a  resource  indicates 
what  we  seek,  an  address  indicates  where  it  is,  and  a  route 
tells  us  how  to  get  there.  [14J 


A  name  is  a  symbol  identifying  a  subscriber.  A 
mechanism  exists  to  map  names  into  addresses.  The  way  in 


which  this  mapping  mechanism  functions  depends  on  the 
choice  of  implementation.  The  mapping  process  may  be 
handled  by  a  central  controller  or  the  mapping  process  may 
be  handled  through  a  distributed  system  of  controllers. 

The  advantage  of  a  central  controller  is  that  changes  in 
the  addresses  of  subscribers  only  have  to  be  made  at  the 
central  controller.  A  disadvantage  to  a  central  controller 
is  a  delay  in  the  mapping  process  due  to  contention  at  the 
central  controller.  An  advantage  to  the  distributed  system 
besides  faster  response,  is  that  of  survivability.  If  the 
central  controller  is  inoperable  for  any  reason,  no  mapping 
can  take  place  in  a  system  with  only  one  controller.  A 
disadvantage  to  a  system  of  distributed  controllers  is  that 
of  updating  changes  in  a  timely  manner.  The  name  is  not 
bound  to  the  address  until  the  mapping  takes  place;  thus 
allowing  the  address  associated  with  the  name  of  a 
particular  subscriber  to  change  over  time. 

The  address  is  the  data  structure  which  defines  the 
subscriber  and  can  be  recognized  by  all  elements. 

Addresses  must  be  meaningful  and  must  be  drawn  from  some 
uniform  address  space.  The  address  space  may  be  either  a 
"flat"  one  which  spans  the  entire  domain  or  it  may  be  a 
heirarchical  address  space  such  as  that  used  in  the  Pup 
internet.  In  a  flat  address  space  the  address  is  not 
divided  into  any  subfields  such  as  the  social  security 
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number  which  is  a  consecutive  nine  digit  field.  In  the  Pup 
internet,  the  address  consists  of  three  parts:  a  network 
number,  a  host  number,  and  a  socket  number  [15:614]. 

When  one  subscri  V  r  wishes  to  communicate  with 
another,  the  address  of  the  destination  subscriber  is 
mapped  into  an  appropriate  route.  The  address  need  not  be 
bound  to  a  route  until  the  mapping  process  takes  place 
allowing  the  route  to  change  over  time.  A  route  is  the 
specific  information  needed  to  forward  a  packet  to  its 
destination  subscriber. 

The  route  mapping  may  be  done  at  the  source  or  at 
intermediate  points  along  the  route.  In  source  routing, 
decisions  for  routing  from  source  to  destination  are  made 
before  the  data  leaves  the  source.  In  intermediate 
routing,  a  decision  is  made  at  every  switching  point,  only 
the  destination  address  is  carried  along  with  the  data. 

In  this  thesis,  the  process  of  mapping  a  name  into  an 
address  is  studied.  The  rest  of  this  chapter  covers 
suggested  solutions  to  the  problem  of  addressing  mobile 
subscribers. 


Da.ta.kasg 


In  the  method  suggested  by  Schoch,  1978,  mobile 
subscribers  are  considered  to  represent  a  special  case  of 
the  multiple  address  problem.  A  multiple  address  occurs 
when  a  subscriber  may  have  two  different  addresses  within  a 


network  or  be  connected  to  two  different  networks.  The 


suggested  solution  is  to  maintain  a  specialized  database  of 
the  mobile  subscribers  current  locations  within  individual 


packet  radio  nets.  The  mobile  subscribers  send  updates  to 
the  database  when  changes  occur.  Subscribers  wishing  to 
communicate  with  the  mobile  subscribers  would  query  the 
database  for  the  current  address.  [4:14]  One  disadvantage 
to  this  solution,  in  adddition  to  its  vulnerability,  is  the 
need  for  a  separate  communication  with  the  database  which 
must  be  successful  before  a  connection  with  a  mobile  sub¬ 
scriber  can  be  made.  Another  complication  to  this  solution 
is  that  as  a  mobile  subscriber  changes  networks,  updates  to 
the  database  must  be  made  in  a  timely  manner.  [8] 

Virtual  iieJts 

The  problem  of  allowing  subscribers  to  move  between 
nets  is  that  the  network  portion  of  the  internet  address  is 
interpreted  as  specifying  the  "real"  network  in  which  the 
subscriber  must  be  found.  A  subscriber  moving  to  a  new 
network  would  have  to  take  on  a  new  internet  address, 
causing  problems  for  higher  level  protocols,  such  as  TCP, 
that  use  the  internet  address  for  identifying  what 
connection  a  packet  belongs  to.  The  suggested  solution  is 
one  in  which  a  "virtual"  net  exists  and  source  routing  is 
used.  A  "virtual"  net  does  not  correspond  to  a  physical 
net,  but  rather  to  a  set  of  subscribers  in  which  names  can 
be  uniquely  assigned.  There  would  be  one  network 
identifier  for  mobile  subscribers  where  the  local  portion 
of  the  internet  address  for  each  packet  radio  would  be  a 
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unique  24-bit  number.  The  network  address  must  then  be 
interpreted  in  a  different  manner  in  internet  routing.  A 
two-part  source  route  must  be  used  to  deliver  packets  to 
airborne  subscribers.  The  first  step  would  be  a  normal 
internet  address  of  a  forwarder  in  the  net  the  source 
subscriber  is  in.  The  mobile  virtual  net  address  in  the 
final  part  of  the  source  route  would  cause  the  forwarder  to 
look  up  in  a  dynamically  maintained  table  of  attached 
mobile  subscribers  what  the  proper  local  address  was  to  the 
specified  mobile  subscriber,  and  forward  the  packet 
accordingly.  This  solution  allows  higher  level  protocols 
to  remain  unchanged  in  their  mapping  of  addresses  to 
connections.  This  freedom  for  higher  level  protocols  has 
its  price  at  the  internet  level.  Source  routing  is 
required,  forwarders  must  maintain  local  address  mappings, 
and  an  appropriate  forwarder  for  each  mobile  subscriber 
must  be  determined.  [5] 

Log-loal  Addressing 

In  many  computer  networks,  the  subscriber  presents  a 
message  to  the  network  with  an  address  corresponding  to  the 
destination  subscriber's  physical  address.  This  method  is 
simple  and  effective,  but  restrictive  in  that  it  requires 
subscribers  to  know  each  other's  physical  locations.  Sub¬ 
scribers  are  not  allowed  to  change  networks  or  to  have 
multiple  network  connections.  [13] 

Logical  addressing  assigns  a  permanent  logical 
address  to  a  subscriber  which  denotes  one  or  more  physical 
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addresses  associated  with  that  subscriber.  The  sending 
subscriber  does  not  need  to  know  the  physical  location  of 
the  destination  subscriber,  and  subscribers  can  relocate 
without  change  of  address.  [133 

Logical  addressing  of  subscribers  requires  some  form 
of  "mapping  table"  for  translation  between  logical  and 
physical  addresses.  These  tables  must  be  stored  at  one  or 
more  locations  in  the  network  and  updated  when  changes 
occur.  The  cost  of  maintaining  these  tables  depends  on  the 
size  of  the  network  and  the  implementation  of  logical 
addressing  selected.  There  are  several  possible  locations 
for  these  tables,  among  those  are:  partial  tables  at  each 
node,  complete  tables  at  each  node,  a  distributed  data  base 
of  tables  at  the  nodes,  or  a  centralized  table  at  one  or 
several  locations.  [16] 

If  there  are  only  a  few  copies  of  the  table  scattered 
around  the  network,  then  nodes  which  do  not  contain  the 
tables  would  have  to  query  the  nodes  that  do  in  order  to 
perform  the  translation  function.  This  is  less  efficient 
both  in  terms  of  overhead  and  response  time  than  placing 
the  table  in  every  node.  Considerations  of  reliability  and 
survivability  also  favor  placing  the  table  in  every  node. 

Several  techniques  for  implementing  logical 
addressing  exist.  Three  of  those  techniques  are  presented 
here:  complete  mapping,  partitioned  mapping,  and 

information  service.  [16] 
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In  the  complete  mapping  approach,  all  subscribers  are 


logically  addressed.  Logical  to  physical  address  mapping 
is  performed  at  the  source  node.  The  mapping  table 
consists  of  N  entries  giving  node  number  and  port  number, 
where  N  is  the  number  of  subscribers.  When  N  is  relatively 
small,  the  cost  of  the  table  in  terms  of  storage  required 
is  insignificant.  However,  as  N  increases  the  costs 
increse  exponentially. 

In  the  partitioned  mapping  approach,  the  mapping 
table  can  be  broken  down  into  several  tables  corresponding 
to  the  parts  of  the  address.  In  the  hierarchical 
addressing  scheme  of  the  ARPAnet  there  would  be  three 
tables.  One  for  the  network,  one  for  the  switch,  and  one 
for  the  port. 

The  information  service  approach  is  based  on  the 
existence  of  one  or  more  information  service  centers  on  the 
network.  The  center  maintains  the  address  mapping  informa¬ 
tion  for  the  network  subscribers  and  provides  it  to  the 
subscribers  upon  demand.  This  approach  is  most  useful  in 
large  networks  in  which  there  are  a  few  large  central  nodes 
and  many  smaller  nodes  with  reduced  capabilities,  t 1 3 3 


Laver 

An  alternate  approach  to  handling  mobile  subscribers 
would  be  to  include  an  additional  protocol  at  the  transport 
level.  This  level  would  operate  directly  above  the  TCP 
layer.  This  scheme  is  based  on  separating  the  TCP 
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connection  identifiers  from  the  physical  addresses. 

Opening  and  closing  TCP  connections  would  be  the 
responsibility  of  this  new  protocol  in  addition  to 
maintaining  data  integrity  as  mobile  subscribers  moved  out 
of  one  network  and  into  another.  The  disadvantage  of  this 
approach  is  the  necessity  to  transfer  the  mobile  host's 
new  address  on  a  three  way  handshake  basis,  before  the  host 
moved  onto  the  new  network. 

Summary 

The  next  chapter  will  include  further  discussion 
of  the  two  proposed  solutions,  logical  and  separate 
addressing,  chosen  to  accomodate  mobile  subscribers  in  an 
internet  environment.  In  this  discussion,  the  two 
solutions  are  compared.  Following  this  discussion  the 
models  used  to  simulate  the  environments  are  discussed. 
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When  the  TCP/IP  protocols  were  designed,  the 


requirement  that  mobile  hosts  must  be  handled  was  not 
included.  Therefore,  changes  to  either  TCP  or  IP  must  be 
made  to  handle  mobile  subscribers  and  still  keep  TCP 
connections  open  while  a  subscriber  moves  from  one  network 
to  another. 

In  this  chapter,  two  solutions  to  the  problem  of 
addressing  mobile  subscribers  in  an  internet  environment 
are  presented.  The  concept  of  logical  and  separate 
addressing  is  discussed.  Next,  the  models  used  in 
analyzing  these  two  solutions  are  presented. 

Logical  addressing  allows  the  subscriber  to  change 
location  without  changing  its  logical  address  or  name. 

This  method  of  addresing  allows  the  TCP  connection  to 
remain  the  same  when  the  physical  address  changes.  This 
occurs  because  the  connection  is  based  upon  the  logical 
address,  not  the  physical  address  as  is  the  case  in  the 
usual  TCP/IP  implementation. 

The  subscriber  sends  the  name  of  the  subscriber  it 
wishes  to  communicate  with  to  the  TCP  module.  The  TCP  sets 
up  the  connection  based  upon  its  logical  address.  When 
the  TCP  sends  out  a  message,  it  sends  the  source  and 
destination  logical  addresses  in  the  TCP  header  to  the  IP 
module  located  in  its'  node.  The  IP  module  handles  mapping 


from  logical  to  physical  addresses.  There  is  additional 
overhead  in  each  segment  as  the  logical  and  physical 
addresses  are  in  the  IP  header.  This  method  of  passing 
addresses  can  be  seen  in  figure  4.  Whatever  routing  scheme 
is  used  is  then  based  on  this  physical  address.  The 
logical  address  is  carried  along  in  the  TCP  header 
throughout  the  network  so  that  mapping  may  take  place 
whenever  desired.  For  instance,  mapping  may  take  place 
only  at  the  source  and  destination  nodes  or  at  every  node 
between  the  source  and  destination  nodes. 

If  the  mapping  takes  place  only  at  the  source  and 
destination  nodes  and  the  subscriber  moves,  then  the 
subscribers'  movement  will  not  be  discovered  until  it 
reaches  the  original  destination.  If  mapping  takes  place 
more  often,  a  segment  may  be  rerouted  before  reaching  the 
original  destination,  thus  shortening  delay.  The  method 
used  in  this  study  is  that  of  mapping  at  each  node. 


logical 

address 


logical 

address 


physical 

address 


Figure  4.  Logical  Addressing 
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A  possible  problem  with  this  addressing  scheme  is 
that  of  a  segment  racing  around  the  network  trying  to  catch 
up  with  a  moving  subscriber.  This  problem  is  more  likely 
to  occur  when  transmission  rates  are  slow,  the  distance 
between  locations  is  small,  and  the  subscribers'  vehicle  is 
f  ast . 

Another  problem  is  that  of  updating  the  mapping 
tables.  Many  methods  have  been  suggested  in  the 
literature  on  routing  tables.  In  this  study,  the  problem 
of  updating  tables  has  been  simplified  greatly.  It  is 
assumed  that  all  tables  are  automatically  updated  by  some 
central  controller  with  no  time  delay. 


Unbinding  the  TCP  address  from  the  IP  address  is  what 
is  meant  by  separate  addresses.  In  other  words,  when  a 
subscriber  is  mobile  and  changes  networks,  the  TCP  address 
remains  static  while  the  IP  address  changes  to  reflect  the 
correct  physical  address. 

The  subscribei  sends  the  name  of  the  subscriber  it 
wishes  to  communicte  with  to  the  TCP  module.  The  TCP 
module  maps  this  name  and  its  host's  name  into  the  physical 
addresses  of  the  destination  and  source  subscribers  and 


passes  these  physical  addresses  to  the  IP  module  in  the 
node  through  the  TCP  header.  The  connection  in  this  case 
would  be  based  upon  the  names,  once  again,  instead  of  the 


physical  address.  This  method  of  passing  addresses  can  be 
seen  in  figure  5 . 


The  major  disadvantage  of  this  method  of  addressing 
is  that  when  a  subscriber  moves  during  a  data  transmission, 
the  move  is  not  discovered  until  the  segment  reaches  the 
original  destination.  Once  the  discovery  is  made,  the  data 
segment  cannot  be  rerouted,  but  must  be  retransmitted  with 
the  new  mapping.  This  is  caused  by  the  fact  that  the  names 
are  not  passed  along  in  the  header  as  in  the  logical 
addressing  method. 

A  problem  which  may  be  encountered  in  this  method 
occurs  when  a  subscriber  moves  during  the  establishment  of 
a  connection.  When  this  happens  the  connection  is  not 
completed  and  the  subscriber  must  start  the  connection 
procedure  over. 


Figure  5.  Separate  Addressing 
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The  main  difference  between  these  two  forms  of 
addressing  is  where  the  mapping  from  names  to  addresses 
takes  place.  In  separate  addressing,  the  mapping  takes 
place  in  the  host  or  the  TCP  module  and  in  the  logical 
addressing  scheme,  the  mapping  takes  place  in  the  node  or 
the  IP  module. 

Another  difference  is  how  a  message  is  handled  when  a 
subscriber  moves  during  transmission.  In  logical 
addressing,  if  the  location  of  the  destination  changes,  the 
message  can  be  rerouted  resulting  in  a  savings  of  time  in 
not  having  to  retransmit  the  message  caused  by  a  timeout. 

In  separate  addressing,  the  only  place  the  mapping  can  take 
place  is  at  either  end  of  the  transmission.  Therefore,  if 
a  message  is  in  transmission  and  the  destination  host 
relocates,  the  message  is  lost  and  must  be  retransmitted. 

In  either  method,  the  connection  is  not  broken  as  only  the 
physical  address  changes,  not  the  separate  or  logical 
address.  In  separate  addressing,  the  connection  must  be 
reestablished  if  the  subscriber  moves  during  the  connection 
process. 

TCP/IP  Qum, iging  Jj&dgJLs 

The  TCP  functions  of  connections  and  data 
communications  are  represented  as  a  network  of  queues  in 
this  simulation  as  depicted  in  figure  6.  The  connection 
procedures  used  by  TCP  opening  and  closing  a  connection  can 


be  seen  in  figure  7.  A  TCP  connection  is  opened  by  TCP  A 
sending  a  synchronize  segment  to  TCP  B.  This  is 
represented  by  the  queues  "connect  request"  and  "connect 
accept”  in  figure  6.  TCP  B  then  sends  a  synchronize  segment 
to  acknowledge  the  synchronize  segment  it  received  from  TCP 
A.  This  is  represented  by  the  queue  "connect  established". 

The  connection  is  now  established  and  data  can  be 
transmitted  with  the  last  acknowledge  as  can  be  seen  in 
line  M  of  figure  7.  A  TCP  connection  is  closed  by  TCP  A 
sending  a  finished  segment  to  TCP  B.  This  is  represented 
by  queues  "close  request"  and  "close  wait".  TCP  B  acknowledges 
the  finished  segment  represented  by  queue  "close  wait-1". 

When  TCP  B  is  ready  to  close,  it  then  sends  a  finished 
segment  of  its  own  to  TCP  A.  This  is  represented  by  queues 
"close  accept"  and  "close  wait -2".  TCP  A  sends  an  acknowledge 
back  to  TCP  B  represented  by  queues  "close  acknowledge"  and 
"close  delay".  TCP  A  then  delays  for  2  MSL  (maximum  segment 
lifetime)  which  is  represented  by  the  queue  "close  delay". 

Using  the  uescriptions  of  the  connection  management  from 
[12]  and  [17],  this  function  was  decomposed  into  the  12 
queue::  connect  req ue s t ( 0T1 ) ,  connect  accept(ORI),  connect 

a -h row : "dge' 0T2) ,  connect  establ i sh(0R2) ,  close 

"T1  ,  close  wait(CRI),  close  wait-1(CT2),  close 
<  >■ !  ,  'icse  wait.-2(CT3),  close  acknowl  edge(  CR3) , 

:*■.  •y'  ";u  ,  and  close  del  ay  r(  CRH ) .  A  connection  is 

*  ‘  -i :  .  t  »'<:  wner.  a  host  starts  the  "connect  request"  queue. 

'•  .  ;  ‘  h  «=*  rs  generates  the  segment  which  is  passed  to 
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Figure  6.  TCP/IP  Queueing  Model 


the  IP  (IP  send  queue)  in  the  node  and  to  the  channel  where 
it  is  routed  to  the  destination  node  (IP  receive  queue). 

At  the  destination  node,  it  is  assumed  that  the  "connection 
accept"  queue  will  always  accept  it.  A  further  assumption 
is  that  only  one  connection  may  exist  at  any  time.  The 
"connection  accept"  queue  in  turn  generates  the  second 
segment  in  the  three-way  handshake,  which  the  first  node 
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always  accepts  at  queue  "connect  establish".  The  third  part 
of  the  handshake  is  passed  through  the  data  send  queue(DTI) 
as  described  in  [12:30].  The  close  connection  process 
follows  similarly  through  the  queues  "close  request",  "close 
wait",  "close  wait-1",  "close  accept",  "close  wait-2",  "close 
acknowledge",  "close  delayt",  and  "close  delayr".  Data 
communications  occurs  through  queues  "data  send"  and  "data 
receive"(DR1 ).  These  queues  are  all  represented  as  M/M/1 
queues . 


TCP  A 
1  .  closed 

2.  syn-sent  - > 

3.  established  < - 

4.  established - data - > 


1 

2 

3  ■ 

4 

5 
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TCP  B 


listen 

sy n- received 
sy n-received 
establ ished 


(a.)  Basic  3-way  handshake  for  connection  synchronization 


TCP  A 


TCP  B 


established  established 

fin-wait-1  - >  close-wait 

fin-wait-2  < -  close-wait 

time-wait  < -  last- ack 

time-wait  - >  closed 

closed 

(b.)  close  sequence 


Figure  7.  TCP  Connection  Management 
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The  modification  to  the  TCP/IP  queueing  models  to 
obtain  the  model  for  logical  addressing  was  simply  to  add  a 
queue  before  the  IP  send  queue.  The  function  of  this  queue 


is  the  mapping  of  logical  addresses  to  physical  addresses. 

A  queue  is  not  needed  before  the  IP  receive  queue  as  the 
logical  address  is  carried  in  the  TCP  header  allowing  the 
IP  module  to  examine  the  logical  address  to  determine  if 
at  proper  destination. 

Instead  of  actually  creating  another  queue,  the 
service  time  of  the  send  queues  are  increased  to  account 
for  the  mapping  process.  The  mapping  time  is  calculated 
in  the  same  manner,  based  on  lines  of  code,  as  is  done  for 
the  other  queues  service  time  in  the  TCP/IP  model.  These 
calculations  are  explained  in  Chapter  4.  The  mapping 
process  adds  a  delay  to  the  IP  send  queue  service  time. 

Modifications  to  the  TCP/IP  model  to  obtain  the  model 
for  separate  addressing  are  similar  to  the  changes  for 
logical  addressing.  The  mapping  of  names  to  addresses 
takes  place  after  each  of  the  TCP  transmit  queues  and 
before  each  TCP  receive  queue. 

Again,  as  in  the  logical  addressing  model,  the 
service  times  for  the  TCP  queues  are  increased  instead  of 
creating  new  queues.  In  separate  addressing,  the  names  are 
not  included  in  the  TCP  header,  therefore  mapping  must  take 
place  at  the  receive  queue  to  verify  that  the  correct 
destination  has  been  reached. 

Summary 

In  this  chapter,  the  two  proposed  solutions  to  the 
problem  of  addressing  mobile  subscribers  are  presented. 
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The  basic  TCP/IP  model  is  examined  and  the  changes  made  to 


this  model  to  implement  logical  and  separate  addressing 


are  presented. 


The  next  chapter  discusses  the  simulation  programs 


created  to  analyze  the  performance  characteristics  of  the 


addressing  methods  presented  in  this  chapter. 


IV.  Simulation 


The  objective  of  the  simulation  is  to  test  the 
proposed  modifications  to  the  TCP/IP  model  to  allow  mobile 
subscribers  by  selecting  and  fixing  some  network 
parameters,  and  then  making  multiple  runs  in  which  the 
remaining  parameters  are  varied.  Though  limited  in  scope, 
the  simulations  provide  performance  characteristics  for 
comparison.  These  performance  characteristics  are  data 
segment  delay  and  throughput.  The  simulations  and  their 
parameters  are  the  topic  of  this  chapter. 

Test  Network 

The  test  network  simulated  is  shown  in  figure  10. 

The  system  of  networks  simulated  was  chosen  so  as  to 
represent  the  typical  environment  for  which  TCP/IP  were 
designed.  This  typical  environment  has  been  described  as  a 
"catenet"  [12:1]  or  an  ARPA  model  [10].  In  this 
environment,  hosts  are  connected  to  a  number  of  networks. 
Each  host,  therefore,  has  access  to  any  other  host  through 
an  arbitrary  path,  comprised  of  a  series  of  networks  and 
gateways,  which  is  determined  by  the  lower  level  protocols. 

In  the  test  network  there  are  three  nodes  and  two 
subscribers.  One  subscriber,  designated  as  host-2  in 
figure  8,  is  the  mobile  subscriber  in  the  simulation  of  the 
logical  and  separate  addressing  models. 

This  simulation  assumes  that  a  datagram  must  pass 
through  four  gateways  on  its  path  between  nodes.  These 
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Figure  8.  The  Simulation  Network 


gateways  are  designated  as  netl  and  net2  in  figure  8. 

Each  gateway  performs  the  functions  of  interpreting  the 
incoming  IP  header  and  building  a  new  IP  header  for  the 
outgoing  datagram. 

■Simulation  Characteristics 

The  path  which  a  message  may  follow  is  called  a  chain 
[19:206].  In  this  simulation,  there  are  three  possible 
chains  for  a  message  to  follow.  The  first  of  these  three 
chains  occurs  only  when  a  connection  is  opened  between  two 
subscribers.  The  second  chain,  which  is  the  path  that  a 
data  message  follows,  is  repeated  until  the  third  chain  is 
activated.  The  third  chain  is  that  of  closing  the 
connection.  The  paths  followed  by  all  three  chains  can  be 
seen  inf igure  9. 
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the  mobility  of  subscribers.  Discussed  first  are  the  fixed 
parameters. 

Arrival  rates  were  selected  aroitrarily  while  the 
service  rates  were  estimated  using  the  partially 
implemented  TCP/IP  network  described  in  [18].  From  the  PLZ 
program  listings  given  in  [18]  and  the  estimate  that  one 
line  of  PLZ  executing  on  a  Z8o  based  system  takes 
approximately  160  msec  (200  nsec  Z80  cycle  time  takes  10 
cycles  per  Z80  instruction  (approx.)  times  8  Z80 
instructions  per  PLZ  line  (approx.))  the  minimum  time 
required  to  build  a  TCP  segment  (header  and  data)  was 
estimated  to  be  3-8-4  E—  3  seconds.  This  minimum  was  used  as 
the  average  service  rate  for  each  of  the  TCP  transmit 
queues  (0T1,  0T2,  DTI,  CT1  ,  CT2,  CT3,  and  CTM  as  shown  in 
figure  6).  However,  if  any  service  rate  less  than  the 
minimum  was  generated  by  the  exponential  distribution 
function,  then  the  average  service  rate  was  used  instead. 

It  was  felt  that  this  better  represented  the  effects  of 
other  processes  competing  for  the  host's  or  nodes  resources 
Similarly,  the  time  to  extract  and  interpret  the  TCP 
header,  the  time  to  build  an  IP  header  and  the  time  to 
extract  and  interpret  an  IP  header  were  found  to  be  3.252E- 
3  seconds  (queues  0 R  1  ,  0R2,  DR1,  C R 1  ,  C R 2 ,  CR ] ,  and  CRM), 
6.56E-3  seconds  (IP  send),  and  6 .2M  E- ?  seconds  (IP 
receive),  respectively.  These  times  were  also  used  as 
mi  n  imums . 


The  time  between  subscribers  changing  locations  was 
calculated  using  an  exponential  distribution  with  an  ave¬ 
rage  time  between  locations  to  be  8.5  minutes.  This  ave¬ 
rage  time  was  based  on  a  vehicle  speed  of  210  km/hr.  The 
assumption  here  is  that  the  vehicle  is  moving  continuously. 

The  type  of  traffic  simulated  is  interactive  with 
varying  arrival  rates.  What  is  meant  by  interactive  traf¬ 
fic  is  that  the  subscribers  exhange  data  segments.  The 
traffic  was  generated  by  exponentially  varying  the  data 
size  that  the  segments  were  to  carry.  Error  rates  were 
assumed  to  be  zero.  In  other  words,  a  segment  that  is 
transmitted  will  be  received  free  of  errors  and  will  not 
have  to  be  retransmitted.  As  seen  in  Chapter  1,  the  maxi¬ 
mum  length  of  a  TCP  header  is  24  octets  and  the  maximum 
length  of  the  IP  header  is  68  octets.  Therefore,  the 
maximum  number  of  overhead  octets  allowed  in  a  TCP/IP 
segment  header  is  92  for  the  baseline  version  and  the 
separate  addressing  version.  There  are  an  additional  8 
octets  for  the  source  and  destination  names  in  the  logical 
addressing  version.  Once  a  connection  is  established,  the 
interarrival  time  intervals  of  interactive  traffic  to  the 
system  is  assumed  exponentially  distributed.  Connections 
and  the  durations  of  the  connections  are  also  established 
and  maintained  assuming  exponential  distributions. 

As  mentioned  in  Chapter  2,  the  maximum  datagram 
length  allowed  by  the  IP  is  64K  octets.  All  hosts  must  be 
prepared  to  accept  datagrams  of  up  to  576  octets  whether 
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they  arrive  whole  or  in  fragments  [12:133*  The  average 
length  of  a  datagram  used  in  this  simulation  is  varied 
between  50  and  500  octets. 


Other  parameters  to  be  selected  include  the  distances 
between  nodes,  the  propogation  delay  in  the  networks  and 
the  data  rate  of  the  transmission  medium.  The  distance 
between  gateways  was  chosen  to  be  30km.  The  average  time 

to  transmit  one  bit  over  a  one  kilometer  link  is  6  microse¬ 
conds  per  kilometer.  The  propogation  delay  per  bit  is 
calculated  to  be  the  distance  between  gateways  multiplied 
by  the  average  time  to  transmit  one  bit.  In  these  simula¬ 
tions  the  propogation  delay  per  bit  is  .0018  sec  (30km  * 
6E-6  sec/km)  [11].  The  transmit  time  between  nodes  is 
found  by  multiplying  the  inverse  of  the  data  rate  by  the 
total  number  of  bits  in  the  datagram.  The  data  rate  is 
1.544Mbps,  which  is  the  CCITT  standard  gross  data  rate  of  a 
channel.  The  total  delay  between  nodes  is  then  the  propo¬ 
gation  delay  of  the  first  bit  plus  the  transmission  time. 

fro grama-Lag  Scheme 

This  section  discusses  the  simulation  program  which 
is  a  modified  version  of  code  found  in  reference  20.  The 
program  organization  is  looked  at  along  with  the  functions 
of  some  of  the  modules.  The  simulation  program  was  written 
in  the  Pascal  language.  The  simulation  program  was  orga¬ 
nized  as  a  set  of  procedures  and  functions  controlled  by  a 
simulation  clock  (figure  10).  Before  the  simulation  be- 


gins,  the  routine  is  setup  by  the  main  program  calling  a 
procedure  named  "initialize".  "Initialize"  reads  input 
variables,  sets  up  routes,  initializes  queue  and  data  seg¬ 
ment  statistics,  and  prints  out  various  input  parameters. 

The  main  program  next  calls  the  procedure  "start". 

The  procedure  "start"  initializes  the  open  connection  and 
close  connection  paths.  An  event  is  inserted  in  the  event 
list  for  the  connect  request  transmit  queue  at  time  cur¬ 
rent  clock  +  time  between  connections  *  InCrandom  //).  An 
event  is  also  inserted  in  the  event  list  for  the  close 
request  transmit  queue  at  time  for  connection  to  begin  + 
length  of  connection  *  ln(random  // ) .  The  system  state  is 
set  to  connect  request. 

The  simulation  is  now  ready  to  begin.  The  main 
program  calls  the  procedure  "loop"  which  runs  through  a 
number  of  connections.  The  basic  algorithm  is  for  an  event 
to  arrive  at  a  queue,  complete  service  at  a  queue,  and  then 
determine  which  queue  to  arrive  at  next.  In  this 
simulation  an  event  can  be  thought  of  as  a  data  segment 
moving  through  the  network. 

After  the  simulation  has  run  a  number  of  connections, 
the  main  program  calls  the  procedure  "printstats". 
"Printstats"  uses  the  statistics  collected  to  calculate 
throughput  and  delay,  then  prints  out  the  results. 

The  procedure  "removef irstevent"  removes  an  event  from 
the  event  list.  "Removef irstevent"  has  a  clock  called 
cumclock  which  is  the  amount  of  time  segments  are  in  the 
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system.  The  datacumclock  is  the  amount  of  time  data  seg¬ 
ments  are  in  the  system,  which  is  also  updated  by  this 
procedure . 

The  procedure  "complete"  updates  statistics  for  the 
queue  just  removed  from  the  event  list  by  procedure 
"removefirstevent". 

The  procedure  "arrive"  updates  statistics  for  the 
queue  determined  by  the  procedure  nextnode.  "Arrive"  in¬ 
serts  an  event  in  the  event  list  to  be  removed  when  service 
is  completed.  The  procedure  "nextnode"  determines  which 
node  is  next  in  the  route  from  one  subscriber  to  the  next. 
This  procedure  is  different  for  logical  and  separate  addre¬ 
ssing.  The  changes  to  the  baseline  code  described  here  is 
found  in  the  following  sections.  In  the  baseline  model  the 
routing  decisions  are  few,  as  the  subscribers  are  nonmo- 
bile.  The  only  queues  where  a  decision  must  be  made  are  at 
the  IP  receive  queues.  These  decisions  are  based  on  the 
system  state.  For  example,  if  the  state  of  the  system  is 
connectreq,  the  receiving  node  would  be  OR 1 ;  if  the  state 
were  closereq,  the  receiving  node  would  be  C R 1 . 

The  structure  charts  and  data  dictionary  for  the 
baseline  model  can  be  seen  in  Appendix  A.  The  program  code 
can  be  found  in  Appendix  B. 

Program  JPoriiT-Lsations  for  Logical  Addressing 

The  changes  to  the  baseline  code  for  the  logical 
addressing  scheme  can  be  seen  in  Appendix  C.  A  new  data 
record  called  subscriber  has  been  created  to  keep  track  of 
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where  each  subscriber  is  located.  Information  relative  to 
the  receiving  subscriber  location  is  vital  to  the  procedure 
"nextnode"  in  determining  where  to  send  the  segment  in 
transit. 


The  changes  to  the  baseline  code  for  the  separate 


addressing  scheme  can  be  seen  in  Appendix  D.  The  data 


record  subscriber,  used  in  the  logical  addressing  scheme, 
is  also  used  here.  Added  to  this  record  are  the 
subscribers'  new  location  after  moving  along  with  a  flag 
called  movedflag  indicating  that  the  subscriber  has  moved 
during  a  transmission.  These  new  items  are  needed  due  to 
the  fact  that  a  segment  cannot  be  rerouted  during 
transmission.  This  fact  is  reflected  in  the  code  found  in 
procedure  "nextnode"  by  the  nextnode  being  set  to  data 
transmit,  DTI,  when  the  data  segment  being  sent  reaches  the 
original  destination  and  finds  that  the  subscriber  is  no 
longer  there.  If  a  subscriber  changes  location  while  a 
connection  is  being  opened,  the  connection  is  broken  and 
must  be  reinitiated.  The  same  connection  is  not 
automatically  reestablished;  the  originating  subscriber 
must  request  a  connection  with  the  destination  subscriber 
again.  This  is  done  in  the  program  by  the  event  list  being 
set  to  empty,  thus  ending  the  simulation  of  that 
connection.  In  this  version,  decision  points  for  routing 
occur  at  the  node-2  IP  send  queue  in  addition  to  each  IP 


receive  queue.  A  decision  point  occurs  at  the  node-2  IP 
send  queue  because  the  receiving  subscriber  may  be  in 
either  netl  or  net2.  See  figure  10  for  network  setup. 


Summary 

The  results  of  the  simulation  along  with  the  analysis 
of  the  results  are  found  in  Chapter  5.  The  effective 
throughput  and  data  segment  delay  are  compared  for  data 
segments  of  varying  size. 


The  results  discussed  in  this  chapter  involve  the 
analysis  of  simulations  of  the  baseline,  logical 
addressing,  and  separate  addressing  models.  The  analysis 
centers  around  several  parameters  which  were  considered  to 
have  the  broadest  potential  effect  on  the  system  throughput 
and  delay.  The  results  of  the  simulation  runs  in  terms  of 
throughput  and  delay  are  summarized  in  Tables  I  and  II  and 
examined  in  the  following  sections.  The  paramters  analyzed 
are  compared  for  various  segment  data  and  header  sizes  and 
when  subscriber-2  is  either  mobile  or  stationary.  The 
different  models  are  examined  when  the  subscribers  are 
stationary  to  determine  the  amount  of  performance 
degradation  to  the  network  when  subscribers  are  mobile. 
First  the  impact  on  the  throughput  performance  is  analyzed, 
then  the  degradation  in  delay  is  examined. 

The  throughput  calculated  is  actually  an  effective 
throughput,  that  is,  based  on  data  only.  The  throughput  is 
calculated  as  the  total  number  of  data  bits  divided  by  the 
total  time  that  segments  are  in  the  system.  For  each 
simulation  run,  the  data  size  was  varied  from  50  to  500 
octets . 

Nonmobile.  This  section  presents  the  results  of  the 
simulation  when  the  subscribers  are  not  mobile.  In  order 
to  compare  nonmobile  with  mobile  results  later,  the 


simulation  is  run  three  times.  In  each  run  subscriber-!  is 
attached  to  node-2.  Subscriber-2  is  attached  to  each  of 
the  three  nodes.  The  results  are  then  averaged  over  the 
three  runs  to  obtain  results  which  can  be  compared  with  the 
mobile  runs.  Each  of  the  three  models  were  simulated  with 
the  TCP/IP  header  size  varying  from  minimum  to  maximum  and 
the  data  size  varying  from  50  octets  to  500  octets. 

In  the  baseline  model  the  simulation  is  run  with 
header  sizes  of  20,  60  and  92  octets.  The  values  of  20  and 
92  are  the  minimum  and  maximum  values  allowed  by  the  TCP/IP 
protocols  and  60  octets  is  a  commonly  used  header  size. 

For  the  three  data  segment  sizes  used,  there  is  very  little 
change  seen  in  the  throughput.  Generally,  there  is  a 
slight  downward  trend  in  throughput  as  the  header  size 
increases,  with  a  large  upward  trend  in  throughput  when 
data  size  increases.  The  throughput  decreases  by  less  than 
.5%  for  the  larg  header  size.  Because  of  this  small  diffe¬ 
rence  due  to  header  size,  the  remaining  discussion  will  be 
based  on  the  average  header  size.  The  throughput  increases 
as  the  size  increases  mainly  due  to  the  channel  use  increa¬ 
sing.  These  results  are  plotted  in  figure  11. 

In  the  logical  addressing  model  the  simulation  is  run 
with  header  sizes  at  28,  68,  and  100  octets.  These  values 
are  obtained  by  adding  the  8  octets  for  address  mapping  to 
the  minimum,  average,  and  maximum  values  used  in  the  base¬ 
line  simulation.  As  in  the  baseline  simulation,  the  throu¬ 
ghput  when  the  header  size  is  at  maximum  size  is  99.8%  of 
the  throughput  for  minimum  header  size. 


+  =  data  size  =  50  octets 
*  =  data  size  =  250  octets 
x  =  data  size  =  500  octets 
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Figure  11.  Baseline  Model,  Nonmobile  Throughput 


In  the  separate  addressing  model,  the  simulation  is 
run  with  header  sizes  at  20,  60  and  92  octets.  As  in  both 
the  previous  models  the  throughput  for  maximum  header  size 
and  the  throughput  for  minimum  header  size  are  almost  the 
same  with  only  .1%  difference. 

In  comparing  the  three  models,  the  trend  is  similar 
for  all  three  header  sizes.  The  throughput  for  the  logical 


addressing  model  is  85.35  of  the  throughput  for  the 
baseline  model  and  88.265  of  the  throughput  for  the 
separate  addressing  model.  Throughput  for  the  separate 
addressing  model  is  96.95  of  the  throughput  for  the 
baseline  model.  This  can  be  seen  in  figure  12. 

Mobile.  This  section  compares  the  results  of  the 
simulation  when  the  subscribers  are  allowed  to  move  around 
the  test  network  system.  Subscriber- 1 ,  the  nonmobile 
subscriber,  is  located  at  node-2.  Subscriber-2,  the  mobile 
subscriber,  starts  at  node-3*  Subscriber-2  is  allowed  to 
move  through  the  network  system  with  an  average  time 
between  changing  location  of  8.5  minutes.  The  mobile 
subscriber  travels  through  the  network  system  in  a  circular 
pattern.  The  mobile  subscriber  rotates  through  node-3, 
node-1,  node-2,  and  then  back  to  node-3  again.  The  results 
of  varying  the  TCP/IP  header  size  for  the  logical  and 
separate  addressing  models  are  presented. 

As  is  the  case  of  nonmobile  subscribers,  the 
throughput  for  maximum  header  size  is  slightly  less  than 
the  throughput  for  minimum  header  size.  There  is  a  .55 
difference  in  throughput  for  the  logical  addressing  model 
and  a  .65  difference  in  the  throughput  for  the  separate 
addressing  model.  The  throughput  for  logical  addressing  is 
93-55  of  the  throughput  for  separate  addressing.  The  data 
for  these  runs  is  plotted  in  figure  13. 
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Nonmobile  versus  mobile.  When  comparing  mobile  to 
nonmobile  in  similar  network  environments,  the  mobile 
throughput  is  70.6%  of  the  nonmobile  throughput  for  logical 
addressing  and  the  mobile  throughput  is  81.3%  of  the  nonmobile 
throughput  for  separate  addressing.  Overall,  the 
throughput  goes  down  when  mobile  subscribers  are  present. 

The  throughput  for  the  separate  addressing  model  is  larger 
than  for  logical  addressing.  The  results  are  plotted  in 
figure  14. 

Delay 

The  delay  is  actually  the  average  data  segment  delay. 
Delay  is  calculated  by  dividing  by  the  "da tacumclock" 

(total  time  data  segments  are  in  the  system)  by  the  total 
number  of  data  segments.  For  each  simulation  run,  the  data 
size  is  varied  from  50  to  500  octets  for  header  sizes  from 
minimum  to  maximum. 

Nonmobile.  This  section  presents  the  results  of  the 
simulation  when  the  subscribers  are  not  allowed  to  move. 

Each  of  the  three  models  are  simulated  with  the  TCP/IP 
header  size  varying  from  minimum  to  maximum  allowed. 

In  the  baseline  model  the  minimum  header  size  creates 
a  delay  which  is  99.6%  of  the  delay  created  when  the  header 
size  is  at  maximum  allowed.  The  results  are  the  same  for 
the  logical  and  separate  addressing  models.  In  general, 
the  delay  increases  as  the  header  size  increases  and  as  the 
data  size  increases,  thus  finding  the  largest  delay  when 
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Figure  14.  Throughput  Summary 


the  data  size  is  500  octets  and  the  header  size  is  92  or 
100  octets. 

In  comparing  the  delays  between  the  three  models,  it 
can  be  seen  that  the  lowest  delay  occurs  in  the  baseline 
model.  The  delay  is  lower  in  the  logical  addressing 
version  than  in  the  separate  addressing  version.  The 
average  delay  for  the  baseline  model  is  82.81  of  the 
delay  for  the  separate  addressing  model  and  861  of 
the  delay  for  the  logical  addressing  model.  These  results 
are  shown  in  figure  15. 


Mobile.  This  section  presents  the  results  of  the 
simulation  when  a  subscriber  is  allowed  to  move  through 
the  system.  The  logical  and  separate  addressing  models 
were  run  with  the  TCP/IP  header  size  varying  from  minimum 
to  maximum  allowed. 

As  was  the  case  for  nonmobile,  the  delay  for  the 
segments  with  a  minimum  header  size  is  99-6%  of  the  delay 
for  the  segments  with  maximum  header  size. 
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In  comparing  the  two  models  with  the  baseline 
version,  which  can  be  seen  in  figure  16,  the  delay  for  the 


separate  addressing  model  is  now  lower  than  the  logical 
addressing  model.  Delays  are  still  longer  for  logical  and 
separate  addressing  than  for  the  baseline  model. 

.Nonmobile  versus  mobile.  In  both  the  logical  and 
separate  addressing  models,  the  delay  increases  in  the 
mobile  runs.  In  the  logical  addressing  model  the  average 
nonmobile  delay  is  98.2%  of  the  mobile  delay  and  the  ave¬ 
rage  nonmobile  delay  is  90.1%  of  the  mobile  delay  in  the 
separate  addressing  model.  These  results  are  plotted  in 
figure  17. 

The  differences  between  the  mobile  and  nonmobile 
delays  appear  to  change  depending  upon  data  size.  The  only 
explanation  for  this  would  be  the  effect  the  simulation 
itself  has  on  the  results.  For  instance,  the  number  of 
times  a  subscriber  moves  during  transmissions  will  affect 
the  delay. 
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Figure  17.  Delay  Summary 
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Table  I 


Throughput  (bits/sec) 


Model 

Data  Size 

Min.  Header 

Ave.  Header 

Max.  Header 

(octets) 

Size 

Size 

Size 

(20  octets) 

(60  octets) 

(92  octets) 

Nonmobile 

50 

10,153 

10,132 

10,122 

Base 

250 

50,427 

50,390 

50,410 

500 

100,445 

100,380 

100,388 

50 

8,838 

8,829 

8,824 

Logical 

250 

43,856 

43,938 

43,922 

500 

87,650 

87,491 

87,449 

50 

8,206 

8,854 

8,575 

Separa  te 

250 

41 ,008 

42,727 

43,922 

500 

81,457 

85,224 

85,100 

Mobile 

50 

6,191 

6,131 

6,177 

Logical 

250 

31 ,349 

30,134 

30,138 

500 

60,149 

60,071 

60,283 

50 

6,828 

6,561 

6,511 

Separate 

250 

32,609 

32,252 

32,087 

500 

63,345 

62,553 

63,588 

Table  II 


Model 


Base 


Logical 


Separa te 


Logical 


Separate 


Delay  (sec) 


Data  Size  Min.  Header 
(Octets)  Size 

(20  octets) 


Ave.  Header 
Size 

(60  octets) 


Max.  Header 
Size 

(92  octets) 


Nonmobile 


50 

.07  47 

.0749 

.0749 

250 

.0757 

.0759 

.0759 

500 

.0769 

.0770 

.0771 

50 

.0868 

.0870 

.0872 

250 

.0880 

.0880 

.0882 

500 

.0891 

.0892 

.0894 

50 

.0902 

.0815 

.0817 

250 

.0912 

.0824 

.0825 

500 

.0928 

.0834 

.0837 

Mobile 


50 

.0861 

.0870 

.0863 

250 

.0857 

.0886 

.0888 

500 

.0891 

.0892 

.0  888 

50 

.0785 

.0815 

.0820 

2  50 

.081  9 

.0828 

.0831 

500 

.0843 

.0852 

.0839 
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To  summarize  the  results,  figure  14  shows  the  overall 
trends  for  throughput  and  figure  17  shows  the  overall 
trends  for  delay.  Figure  14  shows  that  throughput 
decreases  when  logical  or  separate  addressing  is 
implemented  with  the  larger  decrease  resulting  with  logical 
addressing.  Figure  17  shows  the  delay  is  increased  when 
either  scheme  is  implemented  with  a  larger  delay  in  the 
separate  addressing  scheme. 

Chapter  6  contains  conclusions  which  may  be  drawn  from 
the  results  presented  here.  Also  in  Chapter  6  are 
recommendations  for  further  study. 


VI. 


This  chapter  contains  the  conclusions  which  are  based 
on  the  performance  analysis  found  in  Chapter  5.  Also 
contained  in  this  chapter  are  suggestions  for  further  study 
in  this  area. 


As  was  seen  in  Chapter  5,  there  is  a  price  to  pay  for 
mobility.  This  price  is  paid  in  terms  of  decreased 
throughput  and  increased  delay  for  data.  There  are  other 
costs  such  as  more  memory  at  each  node  for  the  logical 
addressing  model  and  at  each  subscriber  for  the  separate 
addressing  model  for  the  address  mapping  function.  The 
impact  the  need  for  additional  memory  for  address  mapping 
has  on  the  alternate  schemes  would  depend  on  the  size  of 
the  network  system  and  the  number  of  subscribers  attached 
to  the  system.  If  there  are  amny  nodes  and  only  a  few 
subscribers,  the  logical  addressing  scheme  would  require  a 
greater  amount  of  additional  memory.  When  the  network 
system  is  small,  i.e.  very  few  nodes,  and  many  subscribers 
are  attached  to  those  nodes,  the  separate  addressing  scheme 
requires  a  greater  amount  of  additional  memory  for  the 
address  mapping  function.  Another  cost  would  be  that  of  a 
central  controller,  or  some  other  scheme  to  monitor  the 
movement  of  mobile  subscribers  and  to  update  the  mapping 
tables.  The  cost  of  a  central  controller  would  be  a 
common  cost  to  any  addressing  scheme,  although  the  actual 
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updating  of  mapping  tables  will  vary  according  to  the 
scheme.  These  other  costs  will  not  be  further  discussed 
here  but  are  nevertheless  an  important  consideration  in 
the  implementation  of  an  alternate  addressing  scheme. 

Indicators  which  are  used  for  comparison  are 
throughput  and  delay.  As  was  seen  in  Chapter  5,  throughput 
decreases  more  for  the  separate  addressing  model  than  for 
the  logical  addressing  model  while  the  delay  has  a  greater 
increase  for  the  logical  addressing  model  that  for  the 
separate  addressing  model.  The  possible  causes  for  these 
increases  and  decreases  and  the  differences  between  the 
models  will  be  looked  at  next. 

The  most  probable  reason  that  the  throughput 
decreases  in  the  separate  addressing  model  is  the  fact 
that  when  a  subscriber  moves  during  transmission  of  a  data 
segment;  that  segment  must  be  retransmitted.  In  the 
logical  addressing  model,  the  data  segment  is  not 
retransmitted,  but  rather  rerouted,  which  would  add  a 
delay,  but  not  as  signficant  as  in  the  separate  addressing 
scheme.  The  biggest  cause  for  decreased  throughput  is  the 
increased  time  at  each  node  due  to  mapping  of  addresses. 

The  increased  delay  in  both  alternate  addressing 
schemes  is  due  to  the  mapping  of  addresses.  The  reason  for 
the  longer  delays  in  the  logical  addressing  model  is  due  to 
the  fact  that  the  mapping  occurs  at  each  node.  In  the 
separate  addressing  model  the  mapping  occurs  only  at  each 
end  of  the  transmission. 
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In  choosing  which  method  of  addressing  is  more  cost- 
effective  in  terms  of  throughput  and  delay,  the  choice 
would  be  separate  addressing.  Although  the  throughput  is 
lower  when  the  subscribers  are  not  mobile,  the  throughput 
is  greater  and  the  delay  is  lower  when  the  subscribers  are 
mobile. 

.ft&gflinm&n d a t i o n s  for  Further  Study 

There  were  many  simplifying  assumptions  made  to 
simulate  this  test  network,  one  of  which  was  the  test 
network  itself.  Expanding  the  test  network  to  contain 
more  that  two  connected  networks  would  require  a  more 
sophisticated  routing  scheme.  One  approach  to  this  problem 
would  be  to  use  a  routing  table.  This  routing  table  would 
find  a  route  for  a  data  segment  to  use  based  on  the  nodes 
that  the  subscribers  are  attached  to.  Allowing  more  than 
one  mobile  subscriber  would  raise  the  problem  of  updating 
the  mapping  table  entries  simultaneously.  In  allowing  both 
subscribers  to  move,  it  would  be  interesting  to  compare  the 
number  of  retransmissions  required,  the  number  of 
connections  to  be  reestablished  in  addition  to  any  changes 
in  throughput  and  delay. 

Analyzing  the  effect  of  errors  in  transmission  in 
both  the  nonmobile  and  mobile  environment  is  another  area 
to  be  investigated.  Errors  in  transmission  could  be 
generated  by  exponentially  varying  the  number  of  good  data 
segments  transmitted  before  an  error  occurs. 
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The  mapping  process  and  its  management  is  in  itself 
an  entire  area  to  be  studied.  There  could  be  a  central 
controller  or  each  subscriber  or  node  could  be  responsible 
for  updating  the  mapping  tables.  Another  problem  is  how 
the  manager  obtains  the  address  of  each  subscriber. 
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APPENDIX  A:  Data 


Dictionary  and  Structure  Charts 

This  appendix  contains  the  data  dictionary  and 
structure  charts  for  the  simulation  programs  used  to 
analyze  the  performance  characteristics  of  mobile 
subscribers  in  a  multi-network  environment.  Included  in 
the  data  dictionary  are  entries  for  all  variables  and 
modules. 


VARIABLE:  arrivalflag 

TYPE:  boolean 

ALIASES:  none 

USED:  insertevent,  arrive 

FUNCTION:  indicates  to  the  procedure  insertevent  that  the 

event  is  from  arrive 


VARIABLE:  avail 

TYPE:  elemptr 

ALIASES:  none 

USED:  insertevent,  remov ef irstev ent ,  initialize 

FUNCTION:  pointer  to  element  record 


VARIABLE:  availrouting 

TYPE:  routingptr 

ALIASES:  none 

USED:  adddestination,  initialize 

FUNCTION:  pointer  of  routingelement  record 


VARIABLE:  avedatasegmentdelay 

TYPE:  real 

ALIASES:  none 

USED:  printstats 

FUNCTION:  how  long  it  takes  a  data  segment  to  propogate 

through  the  system 


VARIABLE:  avemovetime 

TYPE:  real 

ALIASES:  none 

USED:  start,  initialize,  loop 

FUNCTION:  average  amount  of  time  a  mobile  subscriber 

remains  connected  to  a  node 


VARIABLE:  avesegmentdelay 

TYPE:  real 

ALIASES:  none 

USED:  printstats 

FUNCTION:  how  long  it  takes  a  segment  to  propogate  through 

the  system 
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VARIABLE:  clock 

TYPE:  real 

ALIASES:  none 

USED:  endcycle,  insertevent,  removef irstevent,  start, 

arrive,  complete,  initialize,  loop,  printstats 
FUNCTION:  used  to  keep  track  of  time  in  the  simulation 


VARIABLE:  closeq 
TYPE:  integer 

ALIASES:  none 

USED:  loop 

FUNCTION:  indicates  what  queue  is  waiting  on  a  data 

data  segment  to  be  received. 


VARIABLE:  cumclock 

TYPE:  real 

ALIASES:  none 

USED:  removef irstevent ,  printstats,  initialize 

FUNCTION:  time  spent  transmitting  segments 


VARIABLE:  currentdataoctets 

TYPE:  integer 

ALIASES:  none 

USED:  delay,  loop,  arrive,  start,  remov ef irstev ent , 

insertevent,  initialize 

FUNCTION:  number  of  data  octets  in  this  message 


VARIABLE:  currentevent 

TYPE:  state 

ALIASES:  none 

USED:  nextnode,  loop,  start,  detcurrentevent,  getnextl, 

getnext2 

FUNCTION:  state  of  the  simulation 


VARIABLE:  cycles 

TYPE:  integer 

ALIASES:  none 

USED:  endcycle,  start,  printstats,  initiailize 

FUNCTION:  number  of  connections  that  have  been  completed 


VARIABLE:  dataarrival 

TYPE:  real 

ALIASES:  none 

USED:  initialize,  loop 

FUNCTION:  average  time  between  data  segments 
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VARIABLE:  dataclock 

TYPE:  real 

ALIASES:  none 
USED:  loop 

FUNCTION:  time  a  data  event  is  due  to  arrive 


VARIABLE:  datacumclock 

TYPE:  real 

ALIASES:  none 

USED:  removef irstevent ,  printstats,  initialize 

FUNCTION:  amount  of  time  during  simulation  that  data 

segments  were  transmitted 


VARIABLE:  dataretransmit 

TYPE:  integer 

ALIASES:  none 

USED:  nextnode,  printstats,  initialize 

FUNCTION:  number  of  times  data  segments  had  to  be 

retransmitted  because  of  subscriber  mobility  in 
the  separate  addressing  model. 

VARIABLE:  dataseg 

TYPE:  integer 

ALIASES:  none 

USED:  removef irstevent,  start,  loop,  insertevent 

FUNCTION:  number  of  data  segments  outstanding 


VARIABLE:  datause 

TYPE:  real 

ALIASES:  none 

USED:  printstats 

FUNCTION:  percent  channel  is  in  use  transmitting  data 


VARIABLE:  destination 

TYPE:  integer 

ALIASES:  none 

USED:  start,  initialize 

FUNCTION:  indicates  subscriber  that  is  the  receiver  in  the 

connection 


VARIABLE:  done 

TYPE:  boolean 

ALIASES:  none 

USED:  start,  loop,  initialize 

FUNCTION:  indicates  that  no  more  data  segments  should  be 

transmitted 
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VARIABLE:  ef f ectivethroughput 

TYPE:  real 

ALIASES:  none 

USED:  printstats 

FUNCTION:  number  of  data  bits  per  second  transmitted 


VARIABLE:  event 

TYPE:  state 

ALIASES:  none 

USED:  removef irstevent,  loop 

FUNCTION:  indicates  what  state  the  system  is  in  when  the 

event  occurs 


VARIABLE:  exchange 

TYPE:  integer 

ALIASES:  none 

USED:  start 

FUNCTION:  used  to  switch  source  and  destination  nodes 


VARIABLE:  flag 

TYPE:  boolean 

ALIASES:  none 

USED:  start,  main,  insertevent,  loop,  removef irstevent 

FUNCTION:  indicates  that  this  event  is  new 


VARIABLE:  first 

TYPE:  elemptr 

ALIASES:  none 

USED:  nextnode,  insertevent,  removef irstevent,  start, 

initialize,  loop 

FUNCTION:  pointer  to  element  record 


VARIABLE:  holding 

TYPE:  real 

ALIASES:  none 

USED:  subservice 

FUNCTION:  used  to  accumulate  subservice  time  during 

calculation 


VARIABLE:  host 

TYPE:  integer 

ALIASES:  none 

USED:  nextnode,  removefirstever.t,  loop,  start,  insertevent 

FUNCTION:  subscriber  the  message  is  headed  for 
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VARIABLE: 

i 

TYPE:  integer 

ALIASES: 

none 

USED:  adddestination,  printstats,  loop 

FUNCTION: 

represents  a  queue  number 

VARIABLE: 

it 

TYPE:  integer 

ALIASES: 

none 

USED:  subservice 

FUNCTION: 

used  as  the  counting  variable 

VARIABLE: 

j 

TYPE:  integer 

ALIASES: 

none 

USED:  adddestination,  loop 

FUNCTION: 

represents  a  queue  number 

in  a  for  loop 


VARIABLE:  1 

TYPE:  pointer 
ALIASES:  none 

USED:  insertevent 

FUNCTION:  an  elemptr  used  to  step  through  the  event  list 


VARIABLE:  last 
TYPE:  elemptr 

ALIASES:  none 

USED:  insertevent,  remov ef i r stev ent ,  initialize 

FUNCTION:  pointer  to  element  record 


VARIABLE:  location 

TYPE:  integer 

ALIASES:  none 

PART  OF:  subscriber 

USED:  nextnode,  initialize,  loop 

FUNCTION:  indicatgs  where  a  subscriber  is  located 
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VARIABLE:  meanconnectinterarrival 

TYPE:  real 

ALIASES:  none 

USED:  start,  initialize 

FUNCTION:  average  connection  length 
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VARIABLE:  -  meandatasize 
TYPE:  integer 

ALIASES:  none 

USED:  initialize,  printstats,  delay 

FUNCTION:  average  data  segment  size 


VARIABLE:  meaninterarrival 

TYPE:  integer 

ALIASES:  pnone 
USED:  start,  initialize 

FUNCTION:  mean  time  between  connections 


VARIABLE:  mnsvc 

TYPE:  real 

ALIASES:  none 

USED:  subservice 

FUNCTION:  used  to  hold  meanservice  time  passed  to 

subservice  function 


VARIABLE:  movedflag 

TYPE:  boolean 

ALIASES:  none 

PART  OF:  subscriber 

USED:  nextnode,  initialize,  loop 

FUNCTION:  indicates  that  a  subscriber  is  movyng 


VARIABLE:  movetime 

TYPE:  real 

ALIASES:  none 

USED:  start,  loop 

FUNCTION:  time  at  which  the  subscriber  will  move 


VARIABLE:  n 

TYPE:  integer 

ALIASES:  none 

USED:  subservice 

FUNCTION:  number  of  servers  for  a  particular  node 


VARIABLE:  newlocation 

TYPE:  integer 

ALIASES:  none 

USED:  nextnode,  initialize,  loop 

FUNCTION:  indicates  where  a  subscriber  is  moving 


VARIABLE:  nodes 

TYPE:  array  of  records 

ALIARES*  fone 

COMPOSED  OF:  routing 

USED:  nextnode,  adddestination 

FUNCTION:  contains  information  to  route  message  through 

queues 


VARIABLE:  numberevents 

TYPE:  integer 

ALIASES:  none 

USED:  printstats,  initialize,  loop 

FUNCTION:  number  of  events  completed 


VARIABLE:  overallthroughput 

TYPE:  real 

ALIASES:  none 

USED:  printstats 

FUNCTION:  total  number  of  bits  transmitted  per  second 


VARIABLE:  propdelay 

TYPE:  real 

ALIASES:  none 

USED:  initialize,  printstats,  delay 

FUNCTION:  delay  in  channel 


VARIABLE:  q 
TYPE:  integer 

ALIASES:  none 

USED:  nextnode,  endcycle,  detcurrentevent,  insertevent, 

arrive,  complete,  removef irstevent 
FUNCTION:  queue  number 


VARIABLE:  rate 

TYPE:  real 

ALIASES:  none 

USED:  initialize,  printstats,  delay 

FUNCTION:  speed  of  transmission  data 


VARIABLE:  retransmit 

TYPE:  integer 

ALIASES:  none 

USED:  nextnode,  printstats,  initialize 

FUNCTION:  number  of  times  a  connection  was  broken  because 

of  a  mobile  subscriber  in  the  separate 
addressing  scheme 
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VARIABLE:  routing 

TYPE:  routingptr 

ALIASES:  none 

USED:  nextnode,  adddestination 

FUNCTION:  points  to  next  queue  in  route 


VARIABLE:  service 

TYPE:  real 

ALIASES:  none 

USED:  subservice 

FUNCTION:  service  time  calculated  for  each  server 


VARIABLE:  servicetime 

TYPE:  real 

ALIASES:  none 

USED:  arrive 

FUNCTION:  time  an  event  will  spend  in  a  queue  after 

arriving  at  that  queue 


VARIABLE:  source 

TYPE:  integer 

ALIASES : none 

USED:  start,  initialize,  nextnode 

FUNCTION:  indicates  subscriber  that  originated  the 

connection 


VARIABLE:  subscriber 

TYPE:  array  of  record 

ALIASES:  none 

COMPOSED  OF:  location,  newlocation,  movedflag 
USED:  nextnode,  initialize,  loop 

FUNCTION:  used  to  indicate  which  node  a  subscriber  is 

currently  attached  to,  where  its  next 
location  is,  and  if  it's  currently  moving 


VARIABLE:  temp 

TYPE:  ptr 

ALIASES:  none 

USED:  insertevent,  remov ef i r st ev ent ,  adddestination 

FUNCTION:  an  elemptr  used  in  inserting  an  event  into 

the  event  list 


VARIABLE:  tempclock 

TYPE:  real 

ALIASES:  none 

USED:  start,  loop 

FUNCTION:  time  the  connection  should  be  stopped 
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VARIABLE:  time 

TYPE:  real 

ALIASES:  none 

USED:  removefirstevent,  insertevent 

FUNCTION:  time  that  event  should  occur 


VARIABLE:  totalbits 

TYPE:  integer 

ALIASES:  none 

USED:  delay 

FUNCTION:  number  of  bits  in  the  message,  both  data 

and  header 


VARIABLE:  totaldataseg 

TYPE:  integer 

ALIASES:  none 

USED:  insertevent,  printstats,  initialize 

FUNCTION:  total  number  of  data  segments  transmitted 

during  simulation 


VARIABLE:  total  da taoctets 

TYPE:  integer 

ALIASES:  none 

USED:  insertevent,  printstats,  initialize 

FUNCTION:  total  number  of  segments  transmitted  during 

simulation 


VARIABLE: 

totallength 

TYPE:  int 

eger 

ALIASES: 

none 

USED:  ini 

tialize,  loop 

FUNCTION: 

length  of  the  element  record  list 

VARIABLE: 

total  segments 

TYPE:  integer 

ALIASES: 

none 

USED:  insertevent,  printstats,  initialize 

FUNCTION: 

total  number  of  segments  transmitted 
during  simulation 

VARIABLE : 

wait 

TYPE:  boolean 

ALIASES:  none 

USED:  start,  loop 

FUNCTION:  indicates  the  system  is  waiting  on  a 

transmitted  data  segment  to  be  received  before 
the  connection  can  be  closed 
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VARIABLE:  x 

TYPE:  integer 

ALIASES:  none 

USED:  min 

FUNCTION:  used  to  determine  which  is  the  smaller  of 

two  numbers  passed  to  the  function  min 


VARIABLE:  y 

TYPE:  integer 

ALIASES:  none 

USED:  min 

FUNCTION:  used  to  determine  which  is  the  smaller  of 

two  numbers  passed  to  the  function  min 


VARIABLE:  z 

TYPE:  integer 

ALIASES:  none 

USED:  subservice,  start,  arrive,  initialize,  loop 

FUNCTION:  used  as  a  seed  in  the  system  function  random 


i 

V 


'  V  ’  -w  /.  .  ■ „■ 


Modules 


MODULE:  adddesti na ti on 

TYPE:  procedure 

CALLING  MODULES:  Initialize 

MODULES  CALLED:  none 

FUNCTION:  creates  routing  table 


MODULE:  arrive 

TYPE:  procedure 

CALLING  MODULES:  loop 

MODULES  CALLED:  insertevent,  min,  subservice,  delay 
FUNCTION:  simulates  an  event  arriving  at  a  queue 

MODULE:  complete 

TYPE:  procedure 

CALLING  MODULES:  loop 
MODULES  CALLED:  min 

FUNCTION:  simulates  an  event  completing  service  at  a  node 

MODULE:  delay 

TYPE:  function 

CALLING  MODULES:  start 
MODULES  CALLED:  none 

FUNCTION:  calculates  the  delay  due  to  overhead  of  TCP/IP 

headers 


MODULE:  detcur rentev ent 

TYFE:  function 

CALLING  MODULES:  insertevent,  loop 
MODULES  CALLED:  none 

FUNCTION:  determines  what  the  currentevent  should  indicate 

given  a  certain  queue  number  y 


MODULE:  endcycle 

TYPE:  function 

CALLING  MODULES:  loop 
MODULES  CALLED:  min 
FUNCTION:  keeps  track 

connections 


of  the  number  of  simulation 


MODULE:  getnextl 

TYPE:  function 

CALLING  MODULES:  nextnode 
MODULES  CALLED:  none 
FUNCTION:  decermines  nextnode 


for  subscriber  1 
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MODULE:  getnext2 

TYPE:  function 

CALLING  MODULES:  nextnode 
MODULES  CALLED:  none 

FUNCTION:  determines  nextnode  for  subscriber  2 


MODULE:  initialize 

TYPE:  procedure 
CALLING  MODULES:  main 
MODULES  CALLED:  adddestination 

FUNCTION:  initializes  variables  and  routing  table 

MODULE:  insertevent 

TYPE:  procedure 

CALLING  MODULES:  arrive,  start 
MODULES  CALLED:  none 

FUNCTION:  inserts  event  into  event  list  according  to 

time  for  event  to  occur 


MODULE:  loop 

TYPE:  procedure 

CALLING  MODULES:  main 

MODULES  CALLED:  nextnode,  arrive,  complete, 

removef irstevent,  insertevent, 
detcurrentevent ,  subservice,  endcycle 
FUNCTION:  main  loop  of  simulation  program 


MODULE:  main 

TYPE:  program 

CALLING  MODULES:  system 

MODULES  CALLED:  initialize,  start,  loop,  printstats 
FUNCTION:  simulate  network 


MODULE:  min 

TYPE:  function 

CALLING  MODULES:  arrive,  complete 
MODULES  CALLED:  none 

FUNCTION:  returns  smaller  of  two  numbers  input 


MODULE:  nextnode 

TYPE:  function 

CALLING  MODULES:  loop 

MODULES  CALLED:  getnextl,  getnext2 

FUNCTION:  determines  the  next  queue  in  the  routing  of 

events  through  the  system 


MODULE:  printstats 

TYPE:  procedure 
CALLING  MODULES:  main 
MODULES  CALLED:  none 

FUNCTION:  calculates  and  prints  out  statistics 


MODULE:  r emov ef irstevent 

TYPE:  procedure 

CALLING  MODULES:  loop 
MODULES  CALLED:  none 

FUNCTION:  removes  the  first  event  from  the  event  list 


MODULE:  start 

TYPE:  procedure 

CALLING  MODULES:  main 
MODULES  CALLED:  insertevent 

FUNCTION:  startup  procedures  for  a  connection 


MODULE:  subservice 

TYPE:  function 

CALLING  MODULES:  arrive,  loop 
MODULES  CALLED:  none 

FUNCTION:  calculates  n  exponentail  values  for  an  n-stage 

Erlang  distribution 
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NODE-  TITLE:  NUMBER 

A3  Simulate  Connection 


APPENDIX  B:  Code 


This  nppendix  contains  the  code  for  the  baseline 
model.  All  three  simulations  programs  are  based  on  this 


code . 


( 


DATE: 06  N 
VERSION  : 
TITLE:  S 

FILENAME : 
OWNER:  C 

SOFTWARE 
OPERATING 
LANGUAGE: 
CONTENTS  : 


USE: 


FUNCTION  : 


ovember  1984 

1  .0 

imula  te 
thesis. p 

apt.  Gail  M.  Nusz 
SYSTEM:  Network  Simulation 

SYSTEM:  VAX/Unix 

Pascal 

min,  subservice,  nextnode,  endcycle,  adddestination, 
insertevent,  remov ef ir stevent,  delay,  start,  arrive, 
complete,  printstats,  initialize,  detcurrentevent , 
getnextl,  getnext2. 

The  program  "change"  must  be  executed  first.  Change 
is  an  interactive  program  to  load  the  file  "paramfile" 
with  variable  parameters  to  be  used  by  the  simulation. 
To  run  the  simulation  the  file  "base"  should  be 
executed. 

To  simulate  a  mobile  packet-switching  network  with 
TCP/IP  as  protocols. 


) 


program  simulate( input, output, paramfile) ; 
const 

nq  =  3  6  ; 

nio=1;  (*number  of  servers  per  queue*) 
nn=36;  (*number  of  node3*) 

aot1=1;  aot2=2;  adt1s3;  act1=4;  act2=5;  act3=6;  act4=7; 
aor1=8;  aor2=9;  adr1=10;  acr1=11;  acr2=12;  acr3=13;  acr4=14; 
bot  1  =  1  5 ;  bo  t2  =  1 6 ;  bdt1=17;  b  c  1 1  =  1 8 ;  bct2=19;  bct3=20;  bct4=21 
borl =22;  bor2=23;  bdr1=24;  bcr1=25>  bcr2=26;  bcr3=27;  bcr4=28 
s1=29;  r 1 =30 ;  s2=31;  r2=32;  s3=33;  r3=34;  net1=35;  net2=36; 

type 

states ( co nnectreq , connectack, datasnd, closer eq , closewaitl  , 
closewait2,  closedelayt,  connectacc,  connectest, 
datarec, closewait, closeacc, closeack, closedelayr) ; 
(•state  of  connection*) 
elemptr=  ‘element  ; 

el ement= record  (*used  to  store  event  information*) 
time:real;  (*time  that  event  should  occur*) 
par  am : integer ;  (*queue  to  which  event  belongs*) 
new:boolean;  (*event  was  generated  from  outside*) 
se gel ock : r e al ;  (*time  to  transmit*) 
de s t : i n te ger ;  ( *de s ti na tion  host*) 

eventty pe :state ;  (^function  of  node*) 
dataoctets  .’integer  ;  (*  f  of  octets  in  segment*) 

next’.elemptr  (*next  event  in  event  list*) 
e  nd  ; 

routingptr=  * routi ngel ement ; 

rou tingel eme nt= re  cord  (*used  in  determining  nextnode*) 
destination:  1  .  . nq  ;  (*next  queue  to  arrive  at*) 
nextrouting:  routingptr  (*next  queue  in  list*) 
end  ; 


var 


z:integer;  ( ‘used  as  seed  for  random  number  generator*) 

i  :  integer ; 
j  :  i nteger ; 
n urn runs :integer ; 
ns  : integer ; 

overheadoctets:integer; 
tops  :  real  ; 
t  cpr  : r  eal  ; 
i ps : r eal ; 
i pr : r  eal ; 
ne  1 1  ser  :  real  ; 
ne  t2  ser : r eal  ; 
par amf ile : text ; 

f 1 ag : bool ean ;  (‘indicates  an  event  arrived  from  outside  system*) 
do ne : bool ean ;  (*indicates  that  no  more  data  segments  send*) 
dataseg : i nteger ;  (*number  of  data  segments  outstanding*) 
w ai t : bool ean ;  (*system  waiting  to  close  on  data  segment*) 
da tacumcl ock : r eal ;  (*time  spend  transmitting  data  segments*) 
cumcloek : real ;  (*time  spend  transmitting  segments*) 
tempsegclock : r eal ;  (*temp  clock  for  cumclock  and  datacumclock* ) 
tempclock : real ;  (‘time  connection  should  be  stopped*) 
dataarrival : r eal ;  (*time  between  data  segment  accept  4  data  bid*) 
mean conne cti nter arrival : re al ;  (*mean  connection  time*) 
service :real ;  (*temporary  variable  to  check  service  time*) 
f irs t , last , avail : el emptr ;  (*pointers  to  element  record*) 
availrouting:  routingptr;  (*pointer  to  routi ngel ement  record*) 
clock:real;  (*keeps  track  of  total  run  time*) 
meandatasiz e : integer ;  (*average  data  segment  size*) 
rate :real ;  (*speed  of  transmitting  data  over  comm,  medius*) 
propdel ay : r eal  ;  (*delay  in  comm,  medium*) 

to tal da tao c te ts : in teger ;  (*number  of  octets  in  data  segment*) 
t otal se gment s : i nteger ;  (‘number  of  segments  transmitted*) 
to tal da taseg : in teger ;  (‘number  of  data  segments  transmitted*) 
arriv al fl ag : bool ean ;  (‘indicates  to  insertevent  event  from  arrive1 
currentdataoctets : integer ;  (‘number  of  octets  in  current  event*) 
cy cl es : i nteger ;  (‘number  of  cycles  that  have  completed*) 
host : integer ;  ( *who  the  segment  is  headed  for*) 

eventistate;  (*3tate  of  connection*) 

currentevent : state ;  (‘present  state  of  connection*) 
sour ce :integer ;  (*who  the  originator  of  connection  is*) 
de s ti na tion : i n te ger ;  ( *who  the  receiver  of  connection  is*) 

q ueues : array [ 1 .. nq ]  of  (‘characteristics  of  queue*) 
re  cord 

num  ber  se  rv  er  s  :  i  nt  eger  ; 
meanservice :real ; 
removaltime:real  ; 
length  .‘integer  ; 
timelengthchangedrreal  ; 
sum  busy  time :real ; 
numbercompletions :integer ; 
bt  :  real  ; 
no  :  r  eal ; 
end  ; 
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nodes:  array[  1  .  .  nn]  of  (■  *q  ueue  /  serv  er  system*) 
record 

routing:  routingptr 

end  ; 

subscriber:  array[1..3l  of 
record 


location:  integer 

end  ; 

meani nter arriv al :  real;  (*mean  time  between  connections*) 
run,  numberevents :  integer; 
timecyclestarted:real ; 
totallength:  integer; 


. . IflMMI.IIMIMMMMI.IMIIMIMMHMI.IIMIMMM 

DATE:  24  AUG  84 

VERSION:  1.0 

NAME :  min 

MODULE  NUMBER: 

FUNCTION:  returns  the  smaller  of  two  numbers  input. 

INPUTS:  x ,  y 

OUTPUTS:  min 

GLOBAL  VARIABLES  USED:  none 

GLOBAL  VARIABLES  CHANGED:  none 

GLOBAL  TABLES  USED:  none 

GLOBAL  TABLES  CHANGED:  none 

FILES  READ:  none 

FILES  WRITTEN:  none 

MODULES  CALLED:  none 

CALLING  MODULES:  arrive,  complete 

AUTHOR:  CAPT  GAIL  M.  NUSZ 

HISTORY: 

. . . . . 


function  min(var  x , y : i n te ger ) : i n teger ; 

(•determines  the  smaller  of  two  numbers  and  returns  smaller*) 
begin 

if  x<=y  then 
min : =x 
else 

mi  n  :  =  y 
end;  (•min*) 
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(MIMIMMItllMMIIIlMMMIMlimmmMMfMMMMI 

DATE:  24  AUG  84 

VERSION:  1  .0 

NAME:  subservice 

MODULE  NUMBER: 

FUNCTION:  calculates  n  exponential  values  for  an  n-stage 

Erlang  distribution. 

IN PU TS  :  mnsvc,  n 

OUTPUTS:  subservice 

GLOBAL  VARIABLES  USED:  none 

GLOBAL  VARIABLES  CHANGED:  none 

GLOBAL  TABLES  USED:  none 

GLOBAL  TABLES  CHANGED:  none 

FILES  READ:  none 

FILES  WRITTEN:  none 

MODULES  CALLED:  none 

CALLING  MODULES:  arrive,  main 

AUTHOR:  CAPT  GAIL  M.  NUSZ 

HISTORY: 


function  subservice (mnsvc : real ;n :integer) :real ; 
(•subservice  gets  n  exponential  values  for  an  n-stage*) 
(•Erlang  di s tri bution* ) 

(•service  time  is  not  purely  exponential,  we  do  not  •) 
(•allow  service  time  to  be  shorter  than  the  mean  *) 
var  it:integer; 

hoi  ding : real ; 
serv i ce : r eal  ; 
begin 

hoi di ng : r0 . 0  ; 
for  i t :  = 1  to  n  do 
begi  n 

service:=-1 .O*mnsvc*ln(random(z)) ; 
if  service<mnsvc  then 
holding:=holding-mnsvc 
else  hoi  ding :  =  hoi di ng- servi ce ; 

end  ; 

subservice:=holding; 
end;  (•subservice*) 


DATE:  30  OCT  84 

VERSION :  1.0 

NAME :  ge  tnext 1 

MODULE  NUMBER: 

FUNCTION:  determines  nextnode  for  subscriber  1. 

IN  PU  TS :  none 
OUTPUTS:  nextnode 

GLOBAL  VARIABLES  USED:  currentevent 

GLOBAL  VARIABLES  CHANGED:  none 

GLOBAL  TABLES  USED:  none 

GLOBAL  TABLES  CHANGED:  none 

FILES  READ:  none 

FILES  WRITTEN:  none 

MODULES  CALLED:  none 

CALLING  MODULES:  nextnode 

AUTHOR:  CAPT  GAIL  M.  NUSZ 

HISTORY: 


function  ge t nex t 1 : i n te ger ; 
begi  n 

case  currentevent  of 


conne  ctr 

eq  : 

ge 

tne 

x  1 1 

: =  aor 1 

conne  eta 

ck  : 

ge 

tne 

X 1 1 

: =aor2 

datasnd : 

ge 

tne 

x  1 1 

: =adr 1 

cl o  ser eq 

: 

ge 

t  ne 

X  t  1 

:  =acr  1 

closewai 

tl  : 

ge 

tne 

xtl 

: =acr2 

closewai 

t2  : 

ge 

tne 

X  t  1 

:  =  acr3 

cl osedel 

ay  t : 

:  g 

etnext 

1 : =  acr 

end 

end ; ( *get  nex 1 1 • ) 
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(MIMMIIMMItimMMMMimilMMmMMMIMMIMMIMIH 

DATE:  30  OCT  84 

VERSION :  1.0 

NAME :  ge  tnext2 
MODULE  NUMBER: 

FUNCTION:  determines  nextnode  for  subscriber  2. 

INPUTS:  none 

OUTPUTS:  nextnode 

GLOBAL  VARIABLES  USED:  currentevent 

GLOBAL  VARIABLES  CHANGED:  none 

GLOBAL  TABLES  USED:  none 

GLOBAL  TABLES  CHANGED:  none 

FILES  READ:  none 

FILES  WRITTEN:  none 

MODULES  CALLED:  none 

CALLING  MODULES:  nextnode 

AUTHOR:  CAPT  GAIL  M.  NUSZ 

HISTORY: 

mmiMlimMMMIMIIMMfMMMMMMMIIMMmiMHMM) 

function  getnext2 :integer ; 
begin  (*getnext2*) 

case  currentevent  of 
connectreq  : 
connectack : 
datasnd : 
closereq  : 
closewai  tl  : 
closewait2 : 
cl osedel ay  t : 

end 

end;  (*getnext2*) 


ge  tnext2 : =bor 1  ; 
getnext2 : =  bor2 ; 
getnext2 : =bdr1  ; 
getnext2 : =bcr  1  ; 
ge  tnext2  :  =bcr2  ; 
getnext2: =bcr3; 
getnext2 : =bcr4 
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(IIMMIMMMUMMMIIMMMIMIMmiMMIIMIMMtMMimi 

DATE:  30  OCT  84 

VERSION:  2.0 

NAME:  nextnode 

MODULE  NUMBER: 

FUNCTION:  determines  the  next  queue  in  the  routing  of  events 

through  the  system. 

INPUTS:  q,  host 

OUTPUTS:  nextnode 

GLOBAL  VARIABLES  USED:  nodes[j],  currentevent 

GLOBAL  VARIABLES  CHANGED:  none 

GLOBAL  TABLES  USED:  none 

GLOBAL  TABLES  CHANGED:  none 

FILES  READ:  none 

FILES  WRITTEN:  none 

MODULES  CALLED:  none 

CALLING  MODULES:  main 

AUTHOR:  CAPT  GAIL  M.  NUSZ 

HISTORY: 

. . ••• . . . . 


function  nextnode(q :integer;host:integer) :integer; 

(•finds  the  next  node  for  Job  q  to  go  to*) 

(•some  routing  decisions  are  based  on  current  •) 

(•event  state  and  who  the  receiving  host  is  •) 
var 

temp :routingptr  ; 
begin 

if  (  (  q=  aor  1  )  or  (  q=  aor2  )  or  (  q=  adr 1 ) or ( q=  a cr 1 ) or ( q=  acr2 ) or ( q=acr3 ) 

or(q=bor1 )or(q=bor2)or(q=bdr1 )or(q=bcr1 )or(q=bcr2)or(q=bcr3)) 
then 

(•not  a  decision  point,  easy  routing  decision*) 
begin 

temp := no des[q]. routing; 
if  temp=nil  then 
begi  n 

wri tel n( ' nextnode  -  undefined  routing  from  node',q); 
halt 
end ; 

nextnode:  =  temp'>.destination; 
end 

else  if  (  (  q= acr4 ) or ( q  =  bcr 4  )  )  then 
(•at  end  of  connection*) 
nextnode : =99 
else  if  q=net1  then 
begi  n 

if  subs cri ber [ host ]. loca ti on= 1  then 
nextnode :  =  rl 
else  nextnode := r2 ; 
end 


else  if  q=net2  then 
begin 

if  subscri ber [host ]. locations 3  then 

nextnode :  =  r3 
else  nextnode : =r2  ; 
end 

else  if  q=s2  then 
begin 

if  subs cri ber [host ]. locations  1  then 
nextnode : s  ne  tl 

else  if  subscriber[host] ,location=2  then 
nextnode : =r2 
else  nextnode  :  snet2  ; 

end 

else  if  ( { qs rl ) or ( qs r3 ) )  then 
begin 

case  host  of 

1:  nextnode  :  rgetnextl ; 

2:  next node : =getnext2 

end 

end 

else  if  q  =  r2  then 
begin 

if  subs  or i ber [host ]. location<>2  then 
nextnode :  =  s2 
el  se 

case  host  of 

1 : nextnode : sgetnextl ; 

2 : nextnode := get next2 

end 

end 

else  if  q=s1  then 
begin 

if  subscriber [host  ]. locations  1  then 
nextnode : = rl 
else  nextnode : =net1 ; 
end 

else  if  qss3  then 
begin 

if  subscriber[host ] . locations3  then 
nextnode :  =  r3 
else  nextnode : =net2 ; 
end 

else  if  ( ( q= ao t 1 ) or ( q= ao t2 ) or ( q= adt 1 ) 
or(q=act1 )or(q=act2)or(q=act3) 
or ( qs  act4 ) )  then 
case  su bs cri ber [ 1 ] . loca tion  of 
1 :  nextnode  :  =  s 1 ; 

2:  nex tnode : = s2 ; 

3 :  nextnode  :  =  s3 


el  se 

case  subs cri ber [ 2 ] . loca tion  of 
1 :  nextnode : =s 1 ; 

2:  nextnode : =s2 ; 

3:  nextnode:=s3 
end ; 

end;  (•nextnode*) 
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DATE:  24  AUG  84 

V  l  ION :  1.0 

NAME:  endcycle 

MODULE  NUMBER: 

FUNCTION:  keeps  track  of  number  of  simulated  connections. 

INPUTS:  none 

OUTPUTS:  endcycle 

GLOBAL  VARIABLES  USED:  none 

GLOBAL  VARIABLES  CHANGED:  queues[q] 

GLOBAL  TABLES  USED:  none 
GLOBAL  TABLES  CHANGED:  none 
FILES  READ:  none 
FILES  WRITTEN:  none 
MODULES  CALLED:  min 
CALLING  MODULES:  main 
AUTHOR:  CAPT  GAIL  M.  NUSZ 

HISTORY: 


function  endcycle:  boolean; 

(•determines  whether  at  end  of  connection  cycle 
if  so,  endcycle  updates  accumulators* ) 
var  q :  integer ; 
begin 

if  cy  cl  es >numruns  then 
begin 

endcy cl e :  =  tr ue ; 
time cyclestarted:= clock; 
for  q  :  =  1  to  nq  do 
with  queues[q]  do 
begin 

sumbusytime:=(sumbusytime 

+  (clock-timelength  changed) 

*min( length, number3ervers))/numberservers; 
timelengthchanged:=clock; 
bt:=bt  +  sum busy  time; 
nc:=nc+n urn ber completions; 
sumbusytime:=0.0; 
numbercompletions:=0; 
end 

end 
el  se 

endcy  cl e :  =  f al se 
end;  (•endcycle*) 


. . . . . . «... . . . 

DATE:  24  AUG  84 

VERSION:  1  .0 

NAME:  adddesti nation 

MODULE  NUMBER: 

FUNCTION:  creates  routing  table. 

INPUTS:  i,  j 

OUTPUTS:  none 

GLOBAL  VARIABLES  USED:  none 

GLOBAL  VARIABLES  CHANGED:  nodes[i],  availrouting 

GLOBAL  TABLES  USED:  none 

GLOBAL  TABLES  CHANGED:  none 

FILES  READ:  none 

FILES  WRITTEN:  none 

MODULES  CALLED:  none 

CALLING  MODULES:  initialize 

AUTHOR:  CAPT  GAIL  M.  NUSZ 

HISTORY: 

. . . 


procedure  adddesti nation( i ,  j :integer) ; 

(•adds  destination  node  j  to  routing  list  for  node  i») 
var  temp:  routingptr; 
begi  n 

if  availrouting=nil  then 
new( temp ) 
el  se 
begi  n 

temp:  =  avail  routing; 

availrouting:=availrouting~.nextrouting 
end  ; 

temp" .destination:=j; 
temp". nextrouting:=  no des [i ] . routing; 
nodes[i ] . routing: =temp 
end;  ( *adddes ti na tion* ) 
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DATE:  27  AUG  84 

VERSION:  1.0 

NAME:  detcurrentevent 

MODULE  NUMBER: 

FUNCTION:  determines  what 


currentevent  should  indicate 


given  a  certain  queue  number 

INPUTS:  q 

OUTPUTS:  none 

GLOBAL  VARIABLES  USED:  currentevent 
GLOBAL  VARIABLES  CHANGED:  none 
GLOBAL  TABLES  USED:  none 
GLOBAL  TABLES  CHANGED:  none 
FILES  READ:  none 
FILES  WRITTEN:  none 
MODULES  CALLED:  none 
CALLING  MODULES:  insertevent,  main 
AUTHOR:  CAPT  GAIL  M.  NUSZ 

HISTORY: 


function  detcurrentevent(q :integer) :state; 
begin  (*detcurrentevent*) 

case  q  of 


aot  1 

,  bot  1  : 

de  tour 

r entev  ent 

: =connectr eq  ; 

aorl 

,  bor  1  : 

de  tour 

rentevent 

:  =  connectacc  ; 

aot2 

, bot2  : 

detcur 

rentevent 

: =connectack ; 

aor2 

, bor2 : 

detcurrentevent 

:  =  conne ctest ; 

adtl 

,  bdt  1  : 

detcur 

rentevent 

: =da tasnd ; 

adr  1 

,  bdr  1  : 

detcur 

rentevent 

: =datarec ; 

act  1 

,  bet  1  : 

detcur 

rentevent 

:  =closereq ; 

acrl 

,  ber  1  : 

detcur 

rentevent 

:  =  closewait ; 

aet2 

, bct2  : 

detcur 

rentevent 

:  scloaewaiti  ; 

a  cr2 

, bcr2 : 

detcur 

rentevent 

:  =  closeacc ; 

act3 

, bct3  : 

detcur 

rentevent 

:  sclosewai t2  ; 

acr3 

,  bcr3  : 

detcur 

rentevent 

:  =  closeack ; 

act4 

, be  t4  : 

detcur 

rentev  ent 

: =  cl osedel ay  t ; 

acr4 

,  bcr4 : 

detcur 

rentevent 

:  =  closedel ayr  ; 

i  s2  , 

r2 , s3  , 

r3  ,  ne  tl 

,  ne  t2  :  de 

t  currentevent : 

end  ; 

end;  (•detcurrentevent1) 


(MiMMmMMlimmiMIMHIMIIMtfllMMIMMmfMIIMK 

DATE:  24  AUG  84 

VERSION  :  1.0 

NAME:  insertevent 

MODULE  NUMBER: 

FUNCTION:  inserts  event  into  event  list  according  to  time, 

time  for  event  to  occur. 

INPUTS:  time,  q,  flag 

OUTPUTS:  none 

GLOBAL  VARIABLES  USED:  none 

GLOBAL  VARIABLES  CHANGED:  t  o  tal  segment  3 ,  totaldataseg 

GLOBAL  TABLES  USED:  none 

GLOBAL  TABLES  CHANGED:  none 

FILES  READ:  none 

FILES  WRITTEN:  none 

MODULES  CALLED:  none 

CALLING  MODULES:  arrive,  main 

AUTHOR:  CAPT  GAIL  M.  NUSZ 

HISTORY: 

HtimimiimiimimiiHiiHiHHiiiHmiHiHmiiimi) 


pro ce dure  insertevent( time:real ;q :integer ;flag:boolean) ; 
(•insertevent  adds  event  at  time  for  param  q  to  list*) 

(•if  flag  is  true,  new  is  updated  to  true*) 
var  temp,l:  elemptr; 
begin 

if  availsnil  then 
new ( temp ) 
else 

begin  (*previously  used  storage  available*) 
temp :  =  av  ail ; 
avail:=  avail*,  next 
end  ; 

temp* . time:=time; 

(•updates  the  segment  clock  when  at  start  of  new  pass  through*) 
(•network  •) 

if  ( ( q=  ao 1 1 )or(q=aot2)or(q=adt1 )or(q=act1 )or(q=act3)or(q=act4 ) 
or(q=bot1)or(q=bot2)or(q=bdt1)or(q=bct1)or(q=bct2)or(q=bct3) 
or(q=bct4))  then 
temp*. segclock:=clock 
else  tem p*  .  se gel ock  :  =  tem pse gel ock ; 
t  em  p  *  .  par  am  :  =q  ; 
temp* . new :  =  f 1 ag ; 

temp*.dataoctets:=currentdataoctets; 
temp* . dest:=host ; 

(•determine  eventtype*) 

temp*. eventtype: =detcurrentevent( q) ; 
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(•add  event  to  list*) 
if  first  =  nil  then 

begin  (*list  is  empty*) 
f irst :  =  tem p  ; 
last:=temp; 
temp"  .  next :  =nil 
end 

else  if  time<f irst" . time  then 
begin  ( ‘insert  at  beginning*) 
temp" . next : =first  ; 
first:=temp 
end 

else  if  time>=last" . time  then 

begin  (‘insert  at  end  of  list*) 
last" . next :  =  temp ; 
last:=temp; 
temp"  .  next :  =nil 
end 
el  se 

begin  (‘insert  somewhere  in  middle*) 

1 :  =  first ; 

while  time>  =  l"  .  next"  .  time  do 
1 : = 1" . next ; 
temp".next:=l".next; 

1". next:=temp 
end  ; 

(•update  statistics*) 
if  arrivalflag  then 
begi  n 

if  ((q=aot1 )or(q=aot2)or(q=adt1 )or(q=act1 )or 

(q=aet2)or(q=act3)or(q=act4)or(q=bot1)or(q=bot2) 
or ( q  =  bd  1 1 )or(q=bct1 )or(q=bct2)or(q=bct3)or 
( q  =  bctH  )  )  then 

totalsegments:=totalsegments+1 ; 
if  ( ( q=adt1 ) or( q  =  bdt1  )  )  then 
begi  n 

da taseg : =da tase g+1 ; 

totaldataoctets:=totaldataoctets+currentdataoctets; 

end 

else  if  ( ( q= adr 1 ) or ( q= bdr 1 ) )  then 

totaldataseg:  =  totaldataseg+1  ; 

end  ; 

end;  ( • i nse r t ev en t • ) 


. . . . . . . 

DATE:  24  AUG  84 

VERSION :  1.0 

NAME:  removef irstevent 

MODULE  NUMBER: 

FUNCTION:  removes  the  first  event  from  the  event  list 

INPUTS:  time 

OUTPUTS:  event,  q,  host 

GLOBAL  VARIABLES  USED:  none 

GLOBAL  VARIABLES  CHANGED:  first,  da ta cum cl ock 

GLOBAL  TABLES  USED:  none 

GLOBAL  TABLES  CHANGED:  none 

FILES  READ:  none 

FILES  WRITTEN:  none 

MODULES  CALLED:  none 

CALLING  MODULES:  main 

AUTHOR:  CAPT  GAIL  M.  NUSZ 

HISTORY : 

. . 1 1  HHIMI  «  M  I  MIIKMIIMIIMMMM  ) 

procedure  removef irstevent( var  time:real;  var  q:integer; 

var  eventistate;  var  host : i nteger ) ; 

( *removefirstevent  returns  time  t  param  q  e  state  and  h  host  of  first 
event*) 

var  temp:  elemptr; 
begi  n 

if  first=nil  then 
begi  n 

writeln( ' removef irstevent  --  empty  list'); 
halt 
end 
el  se 

begin  (*get  information  from  event  record*) 
if  ( ( q= adr 1 ) or ( q= bdr 1 ) )  then 
dataseg: =dataseg-1 ; 
t ime : = f ir s t" . time; 
q :  =  first" . param  ; 
flag:=first". new; 
host :  =  first" . dest  ; 
event:=first". eventtype; 
currentdataoctets :=first" . dataoctets; 
temp3egclock:=first". segclock; 

(•update  statistics*) 

if  ( ( q=aor1 )or(q=aor2)or(q=adr1 )or(q=acr1 )or(q=acr2) 

or(q=acr3)or(q=acr4)or(q=bor1 )or(q=bor2)or(q=bdr1 )or 
(q=bcr1 )or(q=bcr2)or(q=bcr3)or(q=bcr4) )  then 

begin 

cumclock: =cumclock+clock-first" . segclock; 
if  ( ( q= adr 1 ) or ( q = bdr 1 ) )  then 

datacumcl ock :=datacumclock+ clock-first". segclock; 

e  nd  ; 
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(*put  element  storage  on  available  list*) 
temp: =first ; 
first:=first~.next; 
if  first=nil  then 
last :  =  nil ; 
temp"*  .next  :=  avail  ; 
av  ail :  =  temp 
id 

(•removefirstevent*) 
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DATE:  24  AUG  84 

VERSION :  1.0 

NAME:  delay 

MODULE  NUMBER: 

FUNCTION:  calculates  delay  from  overhead  in  TCP/IP  headers 

INPUTS:  currentdataoctets 

OUTPUTS:  delay 

GLOBAL  VARIABLES  USED:  currentdataoctets 

GLOBAL  VARIABLES  CHANGED:  none 

GLOBAL  TABLES  USED:  none 

GLOBAL  TABLES  CHANGED:  none 

FILES  READ:  none 

FILES  WRITTEN:  none 

MODULES  CALLED:  none 

CALLING  MODULES:  arrive 

AUTHOR:  CAPT  GAIL  M.  NUSZ 

HISTORY  : 


function  delay(currentdataoctets :integer) :real ; 
(•calculates  delay  through  communication  medium*) 
var  to tal bits : integer ; 

begin  (•calculated  delay  through  channels*) 

total  bits :  =  8#(currentdataoctets+overheadoctets); 
delay : =( 1 .0/rate»totalbits)+propdelay; 
end ;  ( •del  ay • ) 


DATE:  24  AUG  84 

V  ERS ION :  1.0 

NAME:  start 

MODULE  NUMBER: 

FUNCTION:  startup  procedures  for  a  connection 

INPUTS:  none 

OUTPUTS:  none 

GLOBAL  VARIABLES  USED:  flag 
GLOBAL  VARIABLES  CHANGED:  none 
GLOBAL  TABLES  USED:  none 
GLOBAL  TABLES  CHANGED:  none 
FILES  READ:  none 
FILES  WRITTEN:  none 
MODULES  CALLED:  insertevent 
CALLING  MODULES:  main 
AUTHOR:  CAPT  GAIL  M.  NUSZ 

HISTORY  : 

. 

procedure  start; 

(•initialization  for  each  connection*) 
var  e x change , x : i n teger ; 
be  gi  n 

dataseg : =0 ; 

wait  :  =  f  al  se  ; 

if  first  Onil  then 

writeln(*  event  list  not  empty first* . param , first" . time ) ; 
cycles  :icycle3+1  ;  ( ‘increuent  number  of  connections*) 

flag:=true;  (*set  flag  to  indicate  event  from  outside*) 
done:  =  false;  (*set  connection  to  allow  data  transfers*) 
exchange  :  =source ;  (•switch  source  and  destination  hosts*) 
source:  rdestination; 
desti nation :=exchange; 
host: =destination; 

(•determine  which  node  to  start  connection  at*) 
if  sour  ce= 1  then 
x : =  ao  1 1 

else 

x : =bot1  ; 

tempclock: =clock-subse rvice( me ancon nectinterarrival, 1 ) ; 
insertevent( tempclock,  x,  flag)  ; 

(•determine  which  node  to  finish  connection  at*) 
if  sour  ce= 1  then 
x :  =  ac  1 1 

el  se 

x : =  be  1 1  ; 

tempclock: =tempclock-meaninterarrival*ln(random( z) ) ; 
insertevent( tempclock, x, flag) ; 

cur r e n t e v en t : = co nne c t r eq ;  (#set  current  event  state  to  beginning*) 
currentdataoctets • =0; 
end;  ( *s  tar  t * ) 
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DATE:  24  AUG  84 

VERSION:  1  .0 

NAME :  arrive 

MODULE  NUMBER: 

FUNCTION:  simulates  an  event  starting. 

INPUTS:  q 

OUTPUTS:  none 

GLOBAL  VARIABLES  USED:  none 

GLOBAL  VARIABLES  CHANGED:  queues[q],  arrivalflag 

GLOBAL  TABLES  USED:  none 

GLOBAL  TABLES  CHANGED:  none 

FILES  READ:  none 

FILES  WRITTEN:  none 

MODULES  CALLED:  insertevent,  subservice,  delay 
CALLING  MODULES:  main 
AUTHOR:  CAPT  GAIL  M.  NUSZ 

HISTORY: 


procedure  arr ive ( q : in teger ) ; 

(•handles  arrival  of  a  job  at  queue  q*) 
var  servi ce time : real ; 
begin 

with  queues[q]  do 
begin 

( •stasti cs») 

s  umbusytime:=3umbusytimei.(clock-timelength  changed) 

*min(length, nuiberservers) ; 
timelengthchanged:= clock; 

( *mechani cs • ) 
length :=length+1 ; 
arrivalflag:=true; 
if  length<=numberservers  then 
begi  n 

if  ( ( q= ne tl ) or ( q= ne t2 ) )  then 
begi  n 

removaltime:=clock-subservice(mean3ervice,numberservers) 
+delay(currentdataoctet3) ; 
insertevent(removal time, q, false) 
end 
else 

begi  n 

servicetime:=-1 .O,meanservice*ln(random( z)) ; 
if  servi ce time <mean servi ce  then 
begin 

removal  time :=clock+meanservice; 
insert event(removaltime,q,false) 
end 


m 

mmm 

§ 

el  se 
begin 

r em ov al ti me := clock* servicetime; 
insertevent(removaltime,q,false); 
end 

end  ; 

end 

else 

begin 

if  ( ( q= ne ti ) or ( q= ne t2 ) )  then 

i  nsert  event  (removal  time- 

subservice(meanserviee, numberserv  ers ) 
+delay(currentdataoctets),q,fal3e) 

el  se 
begin 

servicetime:=-1 .O*ieanaervice*ln(random( z) ) ; 
if  servi ce time<meanservi ce  then 

insertevent(r em oval  time* me anserv ice, q,fal3e) 

else  insertevent(removaltime+3ervieetime,q,false)  ; 
end  ; 

end  ; 

arrivalflag:  =  f al se ; 
end 

end;  (‘arrive*) 
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DATE:  24  AUG  84 

VERSION :  1.0 

NAME:  complete 

MODULE  NUMBER: 

FUNCTION:  simulates  an  event  being  completed. 

IN  PU  TS  :  q 
OUTPUTS:  none 

GLOBAL  VARIABLES  USED:  none 
GLOBAL  VARIABLES  CHANGED:  queues[q] 

GLOBAL  TABLES  USED:  none 
GLOBAL  TABLES  CHANGED:  none 
FILES  READ:  none 
FILES  WRITTEN:  none 
MODULES  CALLED:  none 
CALLING  MODULES:  main 
AUTHOR:  CAPT  GAIL  M.  NUSZ 

HISTORY: 


procedure  compl e te ( q : integer ) ; 

(•handles  completion  of  a  Job  at  queue  q*) 
begin 

with  queues[q]  do 
begin 

( *stasti cs • ) 

number  completions : = number com pi etions+1 ; 
s umbusytIme:=3umbusytime+(clock-timelength changed) 

*min( length , number serv  ers ) ; 
timelengthchanged:= clock; 

( »mechani cs • ) 
length :  =  length-  1  ; 
e  nd  ; 

end;  (*complete*) 
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DATE:  24  AUG  84 

VERSION :  1.0 

NAME:  printstats 

MODULE  NUMBER: 

FUNCTION:  calculates  and  prints  out  statistics. 

INPUTS:  none 

OUTPUTS:  none 

GLOBAL  VARIABLES  USED:  none 
GLOBAL  VARIABLES  CHANGED:  queues[q] 

GLOBAL  TABLES  USED:  none 
GLOBAL  TABLES  CHANGED:  none 
FILES  READ:  none 
FILES  WRITTEN:  none 
MODULES  CALLED:  none 
CALLING  MODULES:  main 
AUTHOR:  CAPT  GAIL  M.  NUSZ 

HISTORY: 


procedure  printstats; 
var 

ef f ectivethroughput :real ; 
overall  throughput :real; 
datause :real ; 
avesegmentdelay :real ; 
avedatasegmentdelay :real ; 

begin 

(•print  statistics*) 
avesegmentdelay: =0.0; 
effectivethroughput:=0.0; 
avedatasegmentdelay:=0.0; 
wri tel n ; 

wri teln( ' number  of  events numberevents : 8 , 

'  simulated  time : ' , clock : 1 0 : 3 ) 5 

wri  teln ; 
wri tel n( 

'queue  utilization  throughput'); 

(•produce  point  estimates  only*) 
for  i  :  =  1  to  nq  do 
with  queues[i]  do 

if  num ber com  pi e ti ons+ tr un c ( nc ) >0  then 
begin 

sumbusytime:=sumbusytime+bt*numberservers; 

numbercompletions:=numbercompletions 

+  trunc ( nc ) ; 

s urn busy  time :  =  sumbusytime  + 

min(length, num  ber  serv  er s ) • 

( clock- timelength changed); 


wri tel n( 1:5, 

sumbusytime/(numberservers*c.lock) :  12:6, 
number  com pletions/ el ock:11:4) 

end  ; 

effectivethroughput:=(totaldataoctets*8)/cum clock; 

ave segment  del  ay :  =  cum clock/ to t al segme nts ; 

over all  through put :  =  ( 8. O*totaldataoctet s+ overheadoctets 

•8.0*totaldataseg)/cumclock; 
data use :  = effective through put /over all  throughput ; 
if  total datasegOO  then 

avedatasegmentdelay: =da ta cum cl ock/ total  da taseg ; 
wri  teln ; 

writeln('  number  of  connections  completed  =  • ,oycies-1); 
writeln(*  eumclock  =  • , cum  cl ock : 1 0  :  3 ) ; 
writeln('  mean  data  size  =  1 , meandatasiz e) ; 
writeln('  rate  =  1 , rate : 1 2 : 3 ) ; 

writeln('  propogation  delay  =  *  ,  propdelay  :  10  :  7)  ; 
writeln('  effective  throughput  =  1 , ef f ectivethroughput : 1 2 : 3 ) ; 
writeln('  overall  throughput  =  1 , overall  throughput : 12 : 3) ; 
writeln('  data  use  =  * , da tause : 5 : 2  )  ; 

writeln('  average  segment  delay  =  ' , avesegmentdelay : 10 : 4) ; 
writeln('  average  data  segment  delay  =  1 , aveda tasegme ntdel ay : 1 0 : 4 ) ; 
writeln('  total  data  octets  =  *, total dataoctets ) ; 
writeln('  total  segments  =  ', total  segments ) ; 
writeln('  total  data  segments  =  * , totaldataseg) ; 
end;  ( *pri nt s tats  * ) 


(lUMfltlMimiMMIMmiMMIMIIIIIMMMMMMMimmK 

DATE:  24  AUG  84 

VERSION:  1.0 

NAME:  initialize 

MODULE  NUMBER: 

FUNCTION:  initializes  variables  and  routing  table. 

INPUTS :  none 

OUTPUTS:  none 

GLOBAL  VARIABLES  USED:  none 
GLOBAL  VARIABLES  CHANGED:  none 
GLOBAL  TABLES  USED:  none 
GLOBAL  TABLES  CHANGED:  none 
FILES  READ:  none 
FILES  WRITTEN:  none 
MODULES  CALLED:  adddes ti na ti on 
CALLING  MODULES:  main 
AUTHOR:  CAPT  GAIL  M.  NUSZ 

HISTORY: 

. . . 


procedure  initialize; 

(•initialization*) 
var  i : integer ; 
y : r eal  ; 

sendnodel :integer; 
se nd no d e2 : integer ; 
begin 

z:=3141;  (*an  arbitrary  value*) 

avail:=nil;  (*no  records  available*) 

avail routi ng := nil ;  (*no  records  available*) 

reset(paramfile) ; 

read(paramfile, numruns ) ; 

r ead ( paramf ile,ns); 

r ead ( par amf il e , meanda tasiz e )  ; 

read ( paramf ile, dataarrival)  ; 

read(paramfile,meaninterarrival); 

read(paramfile,meanconnectinterarrival); 

for  i:=1  to  ns  do 

read(par am file, subscriber[i]. location); 
read ( paramf ile, y ) ; 
read(paramfile, rate) ; 
r ead ( paramf il e , prop del  ay ) ; 
read(paramfile,overheadoctets) ; 
read( par am file, tops ) ; 
read(paramfile, tcpr  ) ; 
read( paramfile,ips)  ; 
read(paramfile, ipr)  ; 
read(paramfile, netlser)  ; 
read(paramfile, net2ser)  ; 

wri tel n( ' datagram  siz e ', meanda tas iz e : 4 , *  octets’); 
w ri t el n ( ' t ime  between  da tagr ams ' , da taar r i v al : 4 : 1 , ’ se c ' ) ; 
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writ el n( ' connection  length' ,meaninterarrival :  5 : 1 , ' sec' ) ; 

w ri tel  n ( 'time  between  connections* , meanconnectinter arrival :  5 : 1) ; 

writeln( ' transmission  rate* , rate: 1 0:2 , '  bps'); 

writeln( 'propogation  delay' ,  pr opdel ay : 8 : 6 , 'sec') ; 

wri teln( ' number  of  octets  in  headers ', overheadoctets : 5 ) ; 

writeln('tcp  send  service  time '  , tops  :  8  :  6 ) ; 

writeln('tcp  receive  service  time ' , t cpr : 8 : 6 ) ; 

writeln('ip  send  service  time '  ,  ips  :  8  :  6 )  ; 

writeln('ip  receive  service  time ' , i pr : 8 : 6 ) ; 

wri  tel  n(  '  ne  tl  transit  time*  ,  netl  ser  :  8  :  6)  ; 

wri teln( ' net2  transit  time 1 , ne t2 ser : 8 : 6 ) ; 

wri teln( ' subscriber  1  attached  to  node ' , subs cri ber [ 1 ] . loca ti on : 3) ; 

wri t el n ( ' su bs cri ber  2  attached  to  node ' , su bs cri ber [ 2 ] . lo ca tion : 3 ) ; 

queues [aotl ]. meanservice := tops ;  (‘service  time  for  servers*) 

queues[aor1 ] ,meanservice:=tcpr; 

queues[aot2] .meanservice:=tcps; 

q  ueues [ a or 2 ] . meanservi ce :  =  t cpr ; 

queuestadtl ] . meanservice .-steps; 

queuea[adr1 ] -meanservice :=tcpr; 

queues[act1 ] .meanservice:=tcps; 

queuestacrl ] .meanservice :=tcpr ; 

queues[act2] -meanservice:=tcps; 

queues[acr2] -meanservice:=tcpr; 

queues[act3] -meanservice:=tcps; 

queues[acr3].meanservice:=tcpr; 

queues[act4] -meanservice:=tcps; 

queues[acr4].meanservice:=tcpr; 

queues[bot1 ] .meanservice : steps : 

queues[bor1].meanservice:=tcpr; 

queues [ bo t2 ] .meanservice : =tcps ; 

queues[bor2] .meanservice i^tcpr; 

queues[bdt1 ].meanservice:stcps; 

queuestbdrl ] ,meanservice:=tcpr ; 

queue3[bct1 ] -meanservice:stcps; 

queues[bcr1].meanservice:stcpr; 

queues[bct2] .meanservice : steps ; 

queues[bcr2].meanservice:=tcpr; 

queues[bct3] .meanservioeistcps; 

queues[bcr3] -meanserviceistcpr ; 

queues[bct4] .meanservice:=tcps; 

queues[bcr4] .meanservice :=tcpr ; 

queuesfsl ] . meanservice :=ips; 

queues[r1 ] -meanservice:=ipr ; 

queues[s2] . meanservice : =ips ; 

queues[r2].meanservice:=ipr; 

queues[s3] .meanservice:=ips ; 

queues[r3] -meanservice:  =  ipr  ; 

queues[net1 ] ,meanservice:=net1ser; 

queues[net2].meanservice:=net2ser; 

for  i:=1  to  35  do  ('sets  number  of  servers  per  queue*) 

queuesti] . numberservers :snio; 
queues[net1 ] .numberservers:=4; 
queues[net2].numberserver3:=4; 


currentdataoctets:=0; 
totaldataoctets:=0; 
totalsegments:=0; 
totaldataseg: =0 ; 
cycles  :  =0 ; 
done :  =  f al se  ; 
source := 1 ; 
destination : =2 ; 
first:=nil; 
last : =nil ; 
clock : =0 . 0 ; 
cumcl ock : =0 . 0 ; 
datacumclock:=0.0; 
number events:=0; 
timecyclestarted:=0.0; 

for  i:sl  to  nq  do 

with  queues[i]  do  (*initialize  queues*) 
begin 

length : =0 ; 

timelengthchanged:=0.0; 
removal  time : =0 . 0 ; 
sum busy  time : =0 . 0 ; 
bt :  =0 . 0; 

number  completions  :  =  0  ; 
nc : =0 . 0 ; 
end ; 

if  subs criber [ 1 ]. locations  1  then 
sendnodel :  =  s  1 

else  if  subscriber [ 1 ]. location=2  then 
sendnodel : = s2 
else  sendnodel : =s3 ; 

if  subs  crib er [2] .location=1  then 
sendnode2 : =s 1 

else  if  subs cri ber [ 2 ] . loca tion= 2  then 
sendnode2 :  =  s2 
else  se ndnode2 : = s3 ; 


adddestination( aotl , sendnodel) 
adddestinatlon(aot2, sendnodel ) 
adddestination(adt1 fsendnode1) 
adddestination(act1 , sendnodel ) 
adddestination(act2, sendnodel  ) 
adddestination(act3, sendnodel) 
adddestination(act4 , sendnodel ) 
adddestination(bot1 , sendnode2) 
adddestination(bot2 , sendnode2) 
adddestination(bdt1 , sendnode2) 
adddestination(bct1 ,sendnode2) 
adddestination(bct2,sendnode2) 
adddestination(bct3 ,sendnode2) 
adddestination(bct4, sendnode2) 
adddestination(aor1 ,aot2); 
adddestination(aor2,adt1  )  ; 
adddestination(adr1  ,adt1  ); 


(•set  up  routing  between  nodes*) 
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adddestination(acr1 , a  ct2 ) 
adddestination(acr2,bct3) 
adddestination(acr3.act4) 
adddesti nation( borl ,bot2) 
adddestination(bor2, bdtl) 
adddesti nation(bdr1 ,bdt1) 
adddestination( bcrl , bct2) 
adddestination(bcr2 , act3) 
adddestination(bcr3, b ct4 ) 
totall ength : =0  ; 
end;  (*  initialize  *) 


. . . 

DATE:  27  AUG  84 

VERSION:  1  .0 

NAME:  loop 

MODULE  NUMBER: 

FUNCTION:  main  loop  of  simulation  program 

INPUTS:  none 

OUTPUTS:  none 

GLOBAL  VARIABLES  USED:  none 
GLOBAL  VARIABLES  CHANGED:  none 
GLOBAL  TABLES  USED:  none 
GLOBAL  TABLES  CHANGED:  none 
FILES  READ:  none 
FILES  WRITTEN:  none 
MODULES  CALLED: 

CALLING  MODULES:  main 
AUTHOR:  CAPT  GAIL  M.  NUSZ 

HISTORY : 

. . . . . 


procedure  loop; 

var  cl oseq : i nteger ;  (•queue  waiting  on  data  segment*) 

da  tael ock : real ;  (*temp  storage  for  dataarrival*) 
begin  (•loop*) 

while  (firstOnil)  and  (not  endcycle)  do  (*loop  for  each  run*) 
begin 

numberevents : =numberevents+1 ; 

removef irstevent ( clock, i , event , host ) ;  (*get  first  event*) 
current event:  =  event; 

if  flag  then  (*if  begin  or  end  of  connection*) 
begin 

arrive ( i ) ; 

currentevent :=detcurrentevent(i) ; 
flag  :  =  f  al  se  ; 

total  1  ength  :  =  to tal  1  ength-*- 1  ; 
end 

else  (*not  beginning  or  ending  of  connection*) 
begin 

compl et e ( i ) ; 

if  ((i=aor1)or(i=aor2)or(i=adr1)or(i=acr1)or(i=acr2) 
or( i=acr3)or( i=bor1 )or( i=bor2)or( i=bdr1 )or( i=bcr1 ) 
or ( i= ber 2 ) or ( i= ber 3 ) )  then 
if  host=1  then 
host : =2 
el se  ho st :  =  1  ; 

if  (  (  1= act  1 ) or ( i= bet  1  )  )  then  (*if  end  of  data  transfer*) 
done :  =  true ; 
j  :  =  nextnode( i, host) ; 
i:  =  j; 


if  ( ( is adt 1 ) or ( is bdt 1 ) )  then 
begin 

currentdataoctets:=trunc(-subservice(meandatasize, 1 ) ) ; 

end ; 

if  (  (  i<>99)and(  ( (  i<  >adt  1  )  and  (  iObdt  1  ) )  )  ) 
then 

begin 

if  ( ( done ) and ( ( i= adt 1 ) or ( i= bdt 1 ) ) )  then 
begin 

if  ( ( wai t ) and ( dataseg=0 ) )  then 
begin 

arrive ( closeq ) ; 
currentevent :=closereq ; 
end  ; 
end 

else  if  ( ( ( i<>acr2 ) and ( i<>bcr2 ) ) or ( dataseg=0 ) )  thei 
begin 

ar ri v e ( i )  ; 

currentevent :=detcurrentevent(i) ; 
end 
el  se 
begi  n 

wai  t  :  =  true  ; 
closeq  :  =  i  ; 
end 

end 

else  if  (  (  (  is adt T ) or ( is bd 1 1  ) )  and 
(  not  done ) )  then 
begin 

dataclock: =clock-dataarrival*ln(random( z) )  ; 
if  da taclockC tempclock  then 

insert event(dataclock, i, true) ; 

end 

else  if  i=99  then 
begin 
start; 

to tal 1 ength : = to tal 1 ength- 1 ; 
e  nd ; 

end 

end  ; 

end;  ( *1 oo  p • ) 
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DATE:  24  AUG  84 

VERSION:  1.0 

NAME:  main 

MODULE  NUMBER: 

FUNCTION:  simulate  network 

INPUTS:  none 

OUTPUTS:  statistics 

GLOBAL  VARIABLES  USED:  non< 
GLOBAL  VARIABLES  CHANGED:  r 
GLOBAL  TABLES  USED:  none 
GLOBAL  TABLES  CHANGED:  nont 
FILES  READ :  none 
FILES  WRITTEN:  none 
MODULES  CALLED:  all  others 
CALLING  MODULES:  none 
AUTHOR:  CAPT  GAIL  M.  NUSZ 

HISTORY: 


begin  (*main*) 

i  ni  ti  al  iz  e  ; 

start;  (*set  up  connection*) 
loop; 

printstats; 


APPENDIX  C:  Logical  Addressing  Code  Changes 


The  following  lines  of  code  are  the  changes  made  to 
the  baseline  code  to  obtain  the  program  for  Logical 
Addressing  model. 


new  variables: 

mov etime :  real  ; 
avemovetime:  real; 

numbermoves:  integer; 

added  to  procedure  start: 

movetime :=tempclock-avemovetime*ln( rand om( z) ) ; 

Added  to  procedure  initialize: 

numbermov es  :  =0  ; 

Added  to  procedure  loop  between  the  lines  marked  by  an 

*currentevent: =  event ; 
if  clock>movetime  then 
begin 

subscriber [2] . location := subscri ber [ 2 ] .location+1 
mov etime :  =  cl ock- av emove t ime *ln ( random(  z ) ) ; 
if  subscriber[2] . location>3  then 
subscriber[2].location:  =  1  ; 
numbermov es : =numbermoves+ 1 ; 
end  ; 

*if  flag  then 


APPENDIX  D: 


tod e  U 


The  following  lines  of  code  are  changes  made  to  the 
baseline  model  to  obtain  the  program  for  the  separate 
addressing  model. 


Added  variables: 

dataretransmit :  integer; 

retransmit:  integer; 

avemovetime:  real; 

movetime :  real ; 

numbermoves:  integer; 

subscriber:  array[1..3J  of 

record 

location:  integer; 

newlocation:  integer; 

movedflag:  boolean 

end  ; 

Additions  to  procedure  start: 

movetime :  =  tempclock-avemovetime*ln( randomC  z) ) ; 

Additions  to  procedure  initialize: 

dataretransmit :=0; 
retransmit : =0 ; 
numbermoves : =0 ; 

subscribed  1 ] .movedflag :=false; 
subscriber[2].movedflag:=false; 

subscribed  1 ] ,newlocation:  =  subscriber[ 1 ] .location; 
subscriber[2] . newlocation:=subscriber[2] .location ; 

Additions  to  procedure  loop: 

if  clock>movetime  then 
begin 

movetime:=clock-avemovetime*ln(random(z)); 
subscriber[2] .newlocation:=subscriber[2] .newlocation+1 
if  su bscr i ber [ 2 ] . newl oca ti on >3  then 
subscriber[2] . newlocation:=1 ; 
subscriber[2] .movedflag:=true; 
numbermoves : =numbermoves+1 ; 


Additions  to  procedure  nextnode: 


> 

i 

» 

i 
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if  subscriberthost] .movedflag  then 
begin 

subscriberthost] .location:=subscriber[host] . new location ; 
subscriber[host].movedflag:=false; 

if  ( ( curr entev ent= da ta snd ) or ( cur rentev ent=data r ec ) )  then 
begin 

dataretransmit:=dataretransmit+1; 
datacumclock:=datacumclock+clock-tempsegclock; 
cumclock: =cumclock+ clock- temps e gel ock; 
dataseg:=dataseg-1 ; 

totaldataoctets:=totaldataoctets-currentdataoctets; 
total  segments :  =  total segments- 1 ; 
if  host=1  then 
nextnode : =bdt1 
else  nextnode : =adt1 ; 

end 
el  se 
begin 

retransmit : =retransmit+1 ; 
cumclock:=cumclock+clock-tempsegclock; 
total  segments : = total  segments- 1 ; 
first :=nil ; 
if  source=1  then 
begin 
host :=2 ; 
nextnode : =act1 ; 
end 
el  se 
begin 

nextnode : =bct1 ; 
host : = 1 ; 
end  ; 

end  ; 
end 
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